"Bert Huijben" <b...@qqmail.nl> writes:
> The only case where you would want to track those moves, is when they are
> also stored in a different place in BASE.
Lets consider moves that do have a base node. I'm trying to determine
what is the correct behaviour for the tests nested_moves_child_first and
nested_moves_child_last in op-depth-tests.c.
Consider two nodes A and A/B and two nested moves. We can either do A/B
to A/B2 before A to A2, or A2/B to A2/B2 after A to A2. Which rows
should get marked moved_here?
State 1: after A to A2
op_depth local_relpath presence moved_here moved_to
0 A normal A2
0 A/B normal
1 A base-deleted
1 A/B base-deleted
1 A2 normal 1
1 A2/B normal 1
All the descendants of A2 are marked moved here. I believe this is the
way it is intended to work.
Now move A2/B to A2/B2 and note that A2/B at op-depth=1 is still marked
moved_here:
State 2: after A to A2 then A2/B to A2/B2
op_depth local_relpath presence moved_here moved_to
0 A normal A2
0 A/B normal A2/B
1 A base-deleted
1 A/B base-deleted
1 A2 normal 1
1 A2/B normal 1
2 A2/B base-deleted
2 A2/B2 normal 1
If the moves are done in the other order the result is that A2/B is not
marked moved_here.
State 3: after A/B to A/B2 then A to A2
op_depth local_relpath presence moved_here moved_to
0 A normal A2
0 A/B normal A2/B
1 A base-deleted
1 A/B base-deleted
1 A2 normal 1
1 A2/B normal
2 A2/B base-deleted
2 A2/B2 normal 1
Which of these is correct, A2/B moved_here or not? This makes a real
difference when reverting the A2/B to A2/B2 move. Reverting state 2 to
state 1 works, but reverting state 3 to state 1 doesn't because A2/B
does not get marked moved_here.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
