Re: Move Tracking in the Update Editor

On 30.08.2013 17:18, Julian Foad wrote:
> Branko Čibej wrote:
>
>> It strikes me that if for update-like edits, which are driven by the
>> server, the once rule is interpreted in terms of WC paths, not node URLs
>> or node IDs; then the server already has all the information it needs to
>> transform the working copy.
>>
>> Take your first multiple source example:
>>
>> | |
>> +-- A mv--\ |
>> | \ |
>> +-- B mv--\ \ |
>> \-\--> +-- C
>>
>> The working copy really doesn't have to know that both A and B became C.
>> It only has to represent the final state. this can be described as:
>>
>> move A, C; delete B
>>
>> or
>>
>> move B, C; delete A
>>
>> and any text modifications are applied after the move.
> That would work for the WC base tree, but is not good enough for handling the local modifications. Consider if the user has made local modifications inside B, and the server sends "move A, C; delete B". If the client told the user:
>
> I've updated A OK (moved it to C).
> Tree conflict: incoming delete of B, local modifications to B.
>
> ... that would be a horrible experience. And it would be arbitrary (from the user's POV) whether she got this conflict or not, depending on which one the server decided to move and which one the server decided to delete.
>
> The client *does* need to know that B is in fact being moved to C, so that it can offer to transfer my local modifications from B to C.

I'm not at all sure that you can avoid a conflict even in this case.
It's either a tree conflict, or a text conflict (if both A and B were
modified, and they refer to the same node).

One possible solution is to replay the moves in the order they happened.
Then you'd get two cases:

  * A is an ancestor of B: the operation is:
      o move(A, B) -> tree conflict, can be resolved as a text merge
      o move(B, C)
  * A and B are the same node: In this case, they'll can only be visible
    at the same time if you have a switched subtree or an external
    subtree, and the multiple-source move doesn't happen (because the
    move needs to be replicated in both subtrees)

I'm not sure how the editor driver would represent the move sequence and
whether the resulting (intermediate) tree conflict should be resolved to
a text conflict automatically or not; but I'm pretty sure it can be done
without introducing multiple-source or multiple-target moves.

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com