Julian Foad <julianf...@btopenworld.com> writes:
>> Now consider a further merge, it will produce a tree conflict it it
>> attempts to modify X/Y, the modifications should go into X/Z. If we
>> record the Y->Z move then merge can avoid the tree conflict.
>
> Precisely -- agreed.
Another example, see move_on_move, the new test 36 in op-depth-tests.c.
Start with two nodes A and A/B, move A/B to B2 and delete A. The move
is recorded properly. Now replace A with a copy that contains another
B, that gives us another A/B that we can move somewhere else:
op_depth local_relpath presence moved_here moved_to
0 A normal
0 A/B normal B2
1 B2 normal 1
1 A normal
1 A/B normal
If I move A/B to B3 that move gets recorded in the A/B base node,
overwriting the move already recorded:
op_depth local_relpath presence moved_here moved_to
0 A normal
0 A/B normal B3
1 B2 normal 1
1 B3 normal 1
1 A normal
1 A/B normal
2 A/B base-deleted
That's probably an error in the current implementation: it should not
record moves in an unrelated base node. That's equivalent to saying
that moves inside copies (copies that are not moves) are not recorded.
As I explained earlier I think we should be recording such moves and the
obvious solution is to record the B3 move in A/B at op-depth=1.
Storing moves like that has consequences. The relpath A/B is now moved
to multiple locations: A/B to B2 and A/B to B3. It also means that to
identify the moved_to associated with a given moved_here is harder, we
should probably change the moved_here column to an op-depth rather than
a simple flag. The _scan_deletion API will probably need to change so
that it can return an array of moves.
I guess this may have implications when it comes to storing moves in the
repository, but I've not given it much though.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
