Re: Move Tracking in the Update Editor

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.

- Julian
Received on 2013-08-30 17:19:20 CEST