Julian Foad <julianf...@btopenworld.com> writes: > Philip Martin wrote: > >> A current Ev1 drive would be: >> >> delete A >> open B >> change_prop B >> close B > > 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 >> B": >> >> move away A id=1 >> move here id=1 B >> change prop B >> close B > > 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@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@10)? It matters -- they're > different sets of changes.
For the update editor it would be best if the B changes were based on B@20 rather than A@10. I don't think the commit editor has to handle this case since it always starts with a single revision and the move source always has to be identical to HEAD. We start with base A@10, working file/dir A' with mods base B@20, working file/dir B' with mods We update to r30 and receive a move move away A, id=1 move here id=1, B change B, ref B@20 close B The move away raises a tree-conflict on A due to local mods, and copies A@10 into a working node and removes the base A@10. We can still identify the local mods by comparing the working A@10 and A'. The move here actions depend on whether B is a directory or a file. For a directory the move here causes B to become B@30/incomplete. At this stage we can still identify the local mods because the incomplete base hasn't received any changes. As changes arrive they have to be merged with the local mods B' possibly causing a conflict. After receiving all the changes the close causes the base to be marked B@30 complete. There may be a conflict. For a file the move here doesn't change wc.db, the text/property changes accumulate until close. At close we create a workqueue item to merge the changes, possibly raising a conflict, and update the base to B@30. The user can then choose to resolve the tree-conflict on A by merging the A@20-A' diff into B'. >> However if B did not exist in the initial working copy the Ev1 drive >> would be different: >> >> delete A >> add B >> change_prop B >> close B > > Agreed. > >> but with Ev1+ we would get the same sequence. So it appears that "move >> here" is somehow replacing both open and add. The driver can >> distinguish these cases and I think it should be telling the receiver. In this case the B changes have to be based on A@10. move away A, id=1 move here id=1, B change B, ref A@10 close B The driver can distinguish these two cases because it has been told whether or not B@20 is present. I don't know whether we need to have the driver explicitly communicate it to the receiver, as with the current add/open. Another case is A-to-B-to-C: We start with base A@10, working A' file/dir with mods base B@20, working B' file/dir with mods We update to r30 and receive two moves: move away A, id=1 move here id=1, C change C close C move away B, id=2 move here id=2, C close C Here the driver chooses to move one of A or B first, I've picked A. After the first move here the driver sends changes based on A@10 since there is no previous C. For the second move there is already a C@30 and the driver has no changes to send. The driver knows all this. For the user there will be tree-conflicts on A and B, there will be working nodes A@10 and B@20, and the local mods can be determined by comparing A@10-A' and B@20-B'. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
