Julian Foad <julianf...@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@10, B@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@10, B@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*
