Re: Move Tracking in the Update Editor

Branko Čibej wrote:

> 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.
[...]
>> 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).

This isn't about trying to avoid a conflict, it's about how the server describes the incoming changes to the client.  The client may raise a conflict, or not, but that must be under the client's control and not an artefact of how the server expresses the edit.

> 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:

('Ancestor' meaning a time-line predecessor of the same node-copy-id.)

>       o move(A, B) -> tree conflict, can be resolved as a text merge
>       o move(B, C)

This is what I meant by "Traversal over URLs or repository nodes" in my document.  In other words, rather than visiting each WC path once, the edit visits each repository node (node-copy-id) once, and sends a series of edits for that node before visiting the next node.

It is a possible approach that could be explored, but it has drawbacks.  (1) If we tried to apply this approach to moves only and not to all edit operations I think that would create a big mess in terms of the editor semantics.  (2) If the WC node at 'A' has local mods and we edit it twice in succession (first when moving to B, again when moving to C) then that increases the likelihood of conflicts compared with if we applied just one big change.  (Because some parts of the first half of the change might be cancelled or rendered non-conflicting by the further changes in the second half.)

>   * 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)

If A points to ^/A_at_10 and B points to ^/A_at_10, then B is switched but the move can't (and shouldn't) be replicated in subtree B because B is the move-root node.

> 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.

Well, I'd love it if you can say how.

- Julian
Received on 2013-08-30 19:15:32 CEST