Re: Move Tracking in the Update Editor

Julian Foad <julianfoad_at_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_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.

For the update editor it would be best if the B changes were based on
B_at_20 rather than A_at_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_at_10, working file/dir A' with mods
  base B_at_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_at_20
  close B

The move away raises a tree-conflict on A due to local mods, and copies
A_at_10 into a working node and removes the base A_at_10. We can still
identify the local mods by comparing the working A_at_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_at_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_at_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_at_30.

The user can then choose to resolve the tree-conflict on A by merging
the A_at_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_at_10.

  move away A, id=1
  move here id=1, B
  change B, ref A_at_10
  close B

The driver can distinguish these two cases because it has been told
whether or not B_at_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_at_10, working A' file/dir with mods
  base B_at_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_at_10 since
there is no previous C. For the second move there is already a C_at_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_at_10 and B_at_20, and the local mods can be determined by
comparing A_at_10-A' and B_at_20-B'.

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*