Stefan Fuhrmann wrote:
> On Fri, Aug 30, 2013 at 2:02 PM, Julian Foad wrote:
> I read the wiki page and agree that all those issues are real.
> So, here is my take on how to address them. Maybe you
> find something useful in there ;)
> Multiple Move Targets
> This can only happen with switched paths in the working copy
> as you need to have a given path_at_rev more than in one in your
> working copy.
> Switched sub-trees are already "isolated" from changes in
> other parts of the working copy in the sense that an update,
> commit or - most importantly - modification in one part does
> not modify any switched sub-tree that happens to mirror these
> If we modify a node in the working copy and that node gets moved
> as part of the update, it is perfectly reasonable to say that
> the local change will not be propagated to any switched sub-tree
> but requires a commit and update cycle to show up there. Even
> if the move was 1:1, it still should not cross switch boundaries
> but appear as a deletion + potential tree conflict during update
> and as an addition in the switched location.
> Finally, having switched sub-trees mirror other parts or the
> working copy seems to be a non-standard usage of the 'switch'
> feature originally designed to make it easy to switch between
> various branches. We have to deal with it but we don't need
> to get fancy here.
I agree with you up to here.
> My suggestion for how the update editor might work (see below)
> allows for multiple copy targets. But for simplicity, the
> client may decide to eliminate moves that cross switched
> sub-tree boundaries.
I'm afraid my gut feeling about your 3-stage suggestion is it's a horrible hack :-) But I don't quite understand it in detail. What I like about it is that the client gets the info about all moves that affect nodes in the WC, even those where it is only going to want to perform a delete or add (half a move) in the end. That's good because it allows the client to make decisions and/or inform the user about exactly how it wants to manage the WC. But I don't like it being two separate client-server communications which partly overlap in content (they both contain *some* info about moves, if I understand you).
> Multiple Move Sources
> This might happen relatively frequently if people move nodes
> over "long distances" in the tree and users update only parts
> of their working copies.
> Again, the update editor should support multiple sources for
> a given move but the client is free to narrow it down to one
> (or even zero).
> For the first implementation, I suggest that the most recent
> (revision-wise) of the move sources is being used and a simple
> deletion is done to all other move sources. Chances are that
> this simply works without being noticed by the user. If there
> were local changes to the older instances of the moved node,
> those will cause tree conflicts as they do today.
> Update Editor / Reporter Drive
> I suggest a 3-stage process:
> (1) Client communicates the working copy path + URL_at_rev list
> to the server and gets a list of all moves relevant to the
> working copy from the server (being tagged with local path
> info in a "baton-esque" manor, i.e. the server does not
> need to understand them). This might be done in a process
> similar to the actual update / reporter drive but will be
> much faster as it only requires wc.db queries.
> (2) Client filters list to eliminate multiple sources as well
> as cross-switch moves. It also knows the list of "move
> from" paths now and can handle them transparently for any
> incoming move or other modification.
> (3) Client passes the filtered list to the normal update editor /
> reporter drive as today. If an ADD happens to match a move
> target, the editor will send a MOVE instead and continue to
> recurse accordingly.
Received on 2013-09-19 16:10:18 CEST