...
When a single-revision BASE tree is updated from one revision to another it temporarily becomes mixed revision (for both v1 and v2 editors). We cannot use the mixed-revision copy representation for these mixed-revision states as mixed-revision copies are represented as multiple-op-depth nested copies. The use of multiple-op-depth for mixed-revision moves would interfere with the use of multiple-op-depth for copies inside move destinations.See MultiLayerMoveUpdate.
A typical move of A/B to X looks like:
op-depth | local-relpath | presence | revision | moved-to | moved-here |
0 | A | normal | 6 |
|
|
0 | A/B | normal | 6 |
|
|
0 | A/B/C | normal | 6 |
|
|
2 | A/B | base-deleted |
| X |
|
2 | A/B/C | base-deleted |
|
|
|
1 | X | normal | 6 |
| 1 |
1 | X/C | normal | 6 |
| 1 |
|
| table A1 |
|
|
|
If the working copy is updated the base tree changes, say from A@6 to A@8 where something inside the deleted tree changes:
op-depth | local-relpath | presence | revision | moved-to | moved-here |
0 | A | normal | 8 |
|
|
0 | A/B | normal | 8 |
|
|
0 | A/B/C | normal | 8 |
|
|
0 | A/B/D | normal |
|
|
|
2 | A/B | base-deleted |
| X |
|
2 | A/B/C | base-deleted |
|
|
|
1 | X | normal | 6 |
| 1 |
1 | X/C | normal | 6 |
| 1 |
|
| table A2 |
|
|
|
At present this produces a tree-conflict on A/B since the changes made to A/B are in the deleted tree. It also "breaks" the move since the move source and destination revisions no longer match. To "fix" the move the destination has to be modified to match the source. This involves changing the revsion of X and X/C, adding new nodes like X/D and removing deleted nodes (none in this example).
op-depth | local-relpath | presence | revision | moved-to | moved-here |
0 | A | normal | 8 |
|
|
0 | A/B | normal | 8 |
|
|
0 | A/B/C | normal | 8 |
|
|
0 | A/B/D | normal |
|
|
|
2 | A/B | base-deleted |
| X |
|
2 | A/B/C | base-deleted |
|
|
|
1 | X | normal | 8 |
| 1 |
1 | X/C | normal | 8 |
| 1 |
1 | X/D | normal | 8 |
| 1 |
|
| table A3 |
|
|
|
We also have to consider updating the working files. File that are unchanged between r6 and r8 need no update. If there are changes between r6 and r8 and the working file is unmodified then the working file can simply be replaced, but if the working file is modified then the r6 to r8 changes need to merged into the working file. Changes to the working file need to be made via the workqueue mechanism so that they happen if and only if the NODES row changes.
Resolving a Conflict Produces New Conflicts
When the move update needs to add or delete rows from the destination, rather than simply updating the revision, that may lead to new tree conflicts. Suppose I start with table A1 and add X/D:
op-depth | local-relpath | presence | revision | moved-to | moved-here |
0 | A | normal | 6 |
|
|
0 | A/B | normal | 6 |
|
|
0 | A/B/C | normal | 6 |
|
|
2 | A/B | base-deleted |
| X |
|
2 | A/B/C | base-deleted |
|
|
|
1 | X | normal | 6 |
| 1 |
1 | X/C | normal | 6 |
| 1 |
2 | X/D | normal |
|
|
|
|
| table C1 |
|
|
|
After the move destination is updated X/D will be 'R'eplaced:
op-depth | local-relpath | presence | revision | moved-to | moved-here |
0 | A | normal | 8 |
|
|
0 | A/B | normal | 8 |
|
|
0 | A/B/C | normal | 8 |
|
|
0 | A/B/D | normal |
|
|
|
2 | A/B | base-deleted |
| X |
|
2 | A/B/C | base-deleted |
|
|
|
1 | X | normal | 8 |
| 1 |
1 | X/C | normal | 8 |
| 1 |
1 | X/D | normal | 8 |
| 1 |
2 | X/D | normal |
|
|
|
|
| table C2 |
|
|
|