Re: Move Tracking in the Update Editor

Julian Foad <julianfoad_at_btopenworld.com> writes:

> Philip Martin wrote:
>> There is a related issue with mixed-revision working copies.  Suppose A
>> gets moved to B in some commit.  A mixed-revision working copy could
>> contain both A and B so what does the update that includes that commit
>> do?  I suppose the server still sends some sort of "move A B" operation
>
> Yes.  That's this scenario:
> <https://wiki.apache.org/subversion/MoveDev/MoveTrackingUpdateEditor#One_Move.2C_One_Non-Move>.
>
>   WC: (A_at_10, B_at_20); repo: (r10: mkdir A; r20: mv A B)
>   Update to r20; A moves to B, and also the existing B is      updated.
>
> and the steps would be:
>
>   move away A; move to B (original A)
>   delete B  # move-away
>   add B (copy-from ... A)  # move-here: it conflicts

Not sure I follow that, we don't want to delete B as it may have local
mods and the final B is the same node so those mods should be preserved.

A current Ev1 drive would be:

    delete A
    open B
    change_prop B
    close B

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

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

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.

>> but we may want the server to tell the client that B is not being
>> replaced.
>
> That happens naturally.  If B is being replaced by the moved A:
>
>   WC: (A_at_10, B_at_10); repo: (r10: mkdir A B; r20: delete B; mv A B)
>   Update to r20; A moves to B, replacing the previous B.
>
> then the server would include an additional "delete A" step:
>
>   move away A; move to B (original A)
>   delete B  # move-away
>   delete A
>   add B (copy-from ... A)  # move-here: it conflicts

There are 3 cases:

    1) A moved to B where B does not exist
    2) A moved to B where B exists and is the same node
    3) A moved to B where B exists but is a different node

1 and 2 are the cases above. For 3 the current Ev1 drive would be:

    delete A
    delete B
    add B
    change prop B
    close B

I suppose the Ev1+ drive might be something like:

    move away A id=1
    delete B
    move here id=1 B
    change prop B
    close B

In this case local mods to B would cause a tree-conflict due to the
delete/replace.

It might be interesting to see how Ev2 would handle these 3 cases.

    1) A moved to B where B does not exist

    alter dir ., children=A,B
    move A B, replaces_rev=-1
    alter B

    2) A moved to B where B exists and is the same node

    alter dir ., children=A,B
    move A B, replaces_rev=-1
    alter B

    3) A moved to B where B exists and is a different node

    alter dir ., children=A,B
    move A B, replaces_rev=N
    alter B

Ev2 distinguishes between add and replace via the replaces_rev flag but
as with Ev1+ the driver knows about the difference between 1 and 2 but
doesn't communicate it to the receiver.

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