[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Move Tracking in the Update Editor

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Fri, 30 Aug 2013 16:18:23 +0100 (BST)

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.