On Wed, Jun 26, 2013 at 02:13:18AM +0200, Branko ?ibej wrote: > On 26.06.2013 01:18, Daniel Shahaf wrote: > > On Wed, Jun 26, 2013 at 01:39:45AM +0300, Daniel Shahaf wrote: > >> gst...@apache.org wrote on Wed, Jan 25, 2012 at 14:45:02 -0000: > >>> Author: gstein > >>> Date: Wed Jan 25 14:45:01 2012 > >>> New Revision: 1235773 > >>> > >>> URL: http://svn.apache.org/viewvc?rev=1235773&view=rev > >>> Log: > >>> Add some clarifications to the Ev2 documentation, based on some IRC > >>> discussions with danielsh. > >>> > >>> * subversion/include/svn_editor.h: > >>> (...): add a section on "Timing and State" to clarify how the > >>> editing calls refer to the receiver's current state. provide a > >>> couple examples. > >>> > >>> Modified: > >>> subversion/trunk/subversion/include/svn_editor.h > >>> > >>> Modified: subversion/trunk/subversion/include/svn_editor.h > >>> URL: > >>> http://svn.apache.org/viewvc/subversion/trunk/subversion/include/svn_editor.h?rev=1235773&r1=1235772&r2=1235773&view=diff > >>> ============================================================================== > >>> --- subversion/trunk/subversion/include/svn_editor.h (original) > >>> +++ subversion/trunk/subversion/include/svn_editor.h Wed Jan 25 14:45:01 > >>> 2012 > >>> @@ -329,6 +329,19 @@ extern "C" { > >>> * for these items are invoked. > >>> * \n\n > >>> * > >>> + * <h3>Timing and State</h3> > >>> + * The calls made by the driver to alter the state in the receiver are > >>> + * based on the receiver's *current* state, which includes all prior > >>> changes > >>> + * made during the edit. > >>> + * > >> Should we change this to say: > >> > >> + * <h3>Timing and State</h3> > >> + * The calls made by the driver to alter the state in the receiver are > >> + * based on the receiver's *initial* state, which excludes all prior > >> changes > >> + * made during the edit. > >> > >> ? > >> > >> I've reviewed the IRC logs referred to in the log msg [1], as well as > >> today's, and I don't see a good reason to stick with the "refers to > >> current state"; and I do see a good reason to use "refers to initial > >> state": that's closer to the final copyfrom (or moved-from) info. > >> I also find "refers to the initial state" more intuitive. > >> > > There was some more discussion on IRC today. > > > > It involved the following case: > > svn mv A B; svn mv B/C D; svn ci; > > > > which could be represented in Ev2 as: > > > > move(A, B); move(B/C, D); > > > > or as: > > > > move(A/C, D); move(B, D); > > > > It's not clear to me yet which of the two options is preferred, or whether > > there are more options. > > There is one option I can think of: always replay the tree modifications > in the exact order in which they happened. That would imply the WC and > FS have to remember the order, and it would also imply that sources are > always from the current txn state.. > > The only nice property the above approach has is that it avoids having > to compute the minimal set of tree modifications. However, it's in > general less efficient in terms of number of operations, and also in > terms of additional knowledge that client and server must have about op > ordering.
And also in not having a unique representation for each tree drive. e.g., it might cause bug reports along the lines of: "'svn mv A/C D; svn mv A B; svn ci' works, but 'svn mv A B; svn mv B/C D; svn ci' doesn't".
