Re: Move Tracking in the Update Editor
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Thu, 5 Sep 2013 13:58:03 +0100 (BST)
Philip Martin wrote:
> Julian Foad <julianfoad_at_btopenworld.com> writes:
Oops, that should be update to r30, and assume that there are changes in each commit as well as the move, because I want to demonstrate that there are two different sets of incoming changes when we update.
>> and the steps would be:
Notation. I was using the notation of sending the move info in a separate prefix and then using the existing "delete" and "add-with-copy" instructions to actually execute the "move-away" and "move-here" operations respectively.
Nevertheless, you bring up a good problem. I agree "we" (the client) quite likely do not want to delete B in such a case; the most likely conflict resolution we'd choose would be to merge the local mods from A into those in B. But I was trying to envision an edit driver in the server that does not make that decision but rather sends commands for each of the two original paths separately and lets the receiver (client) decide how to handle the conflict.
However, I see the problem with that. There is no sane way for the driver to describe both the move from A to B and the update to the original B in the same edit drive.
Switching to Ev1.5 notation with "move-away" and "move-here" as first class operations, as described in <http://wiki.apache.org/subversion/MoveDev/Ev15MovesDesign#Specification>, the move from A to B would be:
and the update to the original B would be:
I suppose the edit driver *could* just send both sets of instructions, one after the other, but that's pretty severely overloading the editor definition. It likely would not play nicely with lazy/late closing of the directories, which I think we do these days.
The alternative is for the merging (and conflict resolution?) to happen earlier. Is that feasible? In the server where it receives a report of the WC base state and drives the editor, perhaps?
> A current Ev1 drive would be:
Right. Note that here the changes in B are expressed relative to the pre-existing 'B' base state.
> For the Ev1+ drive we add move and drop the "delete A" and "open
Well, now, are you thinking that the "move here" operation just conveys a semantic intent but does not actually do anything to B, and then editor expresses the necessary changes in B relative to the existing base state at path B (^/B_at_20); or that the "move here" executes a move (or copy) of the base state in the WC and expresses the changes relative to that state (^/A_at_10)? It matters -- they're different sets of changes.
> However if B did not exist in the initial working copy the Ev1 drive
> but with Ev1+ we would get the same sequence. So it appears that "move
My definition in the Wiki has "move-here" meaning to actually move the referenced base state to the target path, and any following edits will be based on that new state.
(I can't usefully respond to the remainder below until we get more precise in our notation.)
>>> but we may want the server to tell the client that B is not being
This is an archived mail posted to the Subversion Dev mailing list.