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.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2013-06-26 02:13:54 CEST