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:
> >> gstein_at_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".
Received on 2013-06-26 02:17:47 CEST