Branko Čibej <brane_at_wandisco.com> writes:
> 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.
Allowing multiple moves to the same destination doesn't really fit with
Ev2 but I can imagine an enhanced Ev1 editor drive that does
move away A
move to C (original A)
del A
move away B
move to C (original B)
del B
add C
The deletes lead to tree-conflicts on A and B due to local mods. The
add creates a pristine C with no local mods. The user resolves the
tree-conflicts post-update and gets to choose which local mods are
merged to C, possibly both but one before the other, which may in turn
raise text/prop/tree-conflicts on C.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Received on 2013-08-30 18:45:01 CEST