Re: Move Tracking in the Update Editor
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Fri, 30 Aug 2013 18:12:06 +0100 (BST)
Branko Čibej wrote:
> On 30.08.2013 17:18, Julian Foad wrote:
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.
('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
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
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
Well, I'd love it if you can say how.
This is an archived mail posted to the Subversion Dev mailing list.