You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Shahaf <da...@apache.org> on 2013/06/26 01:18:45 UTC
Re: svn commit: r1235773 -
/subversion/trunk/subversion/include/svn_editor.h
On Wed, Jun 26, 2013 at 01:39:45AM +0300, Daniel Shahaf wrote:
> gstein@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.
Daniel
> Daniel
>
> [1] http://colabti.org/irclogger/irclogger_log/svn-dev?date=2012-01-25
> [2] http://colabti.org/irclogger/irclogger_log/svn-dev?date=2013-06-26
>
> > + * Example: copy A to B; set-props on A; copy A to C. The props on C
> > + * should reflect the updated properties of A.
> > + *
> > + * Example: mv A@N to B; mv C@M to A. The second move cannot be marked as
> > + * a "replacing" move since it is not replacing A. The node at A was moved
> > + * away. The second operation is simply moving C to the now-empty path
> > + * known as A.
> > + *
> > * <h3>Paths</h3>
> > * Each driver/receiver implementation of this editor interface must
> > * establish the expected root path for the paths sent and received via the
> >
> >
Re: svn commit: r1235773 -
/subversion/trunk/subversion/include/svn_editor.h
Posted by Daniel Shahaf <da...@apache.org>.
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@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".
Re: svn commit: r1235773 - /subversion/trunk/subversion/include/svn_editor.h
Posted by Branko Čibej <br...@wandisco.com>.
On 26.06.2013 01:18, Daniel Shahaf wrote:
> On Wed, Jun 26, 2013 at 01:39:45AM +0300, Daniel Shahaf wrote:
>> gstein@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.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: svn commit: r1235773 - /subversion/trunk/subversion/include/svn_editor.h
Posted by Julian Foad <ju...@btopenworld.com>.
I (Julian Foad) wrote:
> Hi Daniel. I could begin to address your question, but discussion of Ev2 move
> design is such a big and tricky topic (witness the several hours on IRC today)
> that I would humbly request you start a thread with 'Ev2' in the subject
> line so we can all track it. Your question here doesn't seem to be one that
> merely concerns r1235773 and can be answered with 'yes' and a follow-up
> commit.
Let me be clear: I'm going to be off line for a few weeks and when I come back I'm going to delete all "Re: svn commit: rXXXXXX" emails and still want to be able to read any design discussion emails. That's why this request for a subject line is important to me. Even when a particular commit was the trigger for the question, as it was here. Thanks.
- Julian
Re: svn commit: r1235773 - /subversion/trunk/subversion/include/svn_editor.h
Posted by Julian Foad <ju...@btopenworld.com>.
Daniel Shahaf wrote:
> On Wed, Jun 26, 2013 at 01:39:45AM +0300, Daniel Shahaf wrote:
>> gstein@apache.org wrote on Wed, Jan 25, 2012 at 14:45:02 -0000:
>>> + * <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.
Hi Daniel. I could begin to address your question, but discussion of Ev2 move design is such a big and tricky topic (witness the several hours on IRC today) that I would humbly request you start a thread with 'Ev2' in the subject line so we can all track it. Your question here doesn't seem to be one that merely concerns r1235773 and can be answered with 'yes' and a follow-up commit.
> 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);
I assume the copy-source refers to the current state rather than the initial state in these two options, but either way that second option doesn't make sense, since there is no node 'B' available to be moved.
- Julian