Branko Čibej <br...@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*
