| -*- text -*- |
| |
| TREE CONFLICTS USE CASES AND DESIRED BEHAVIOURS |
| |
| |
| Issue reference: http://subversion.tigris.org/issues/show_bug.cgi?id=2282 |
| |
| (These use cases are based on a scenario paper "SVN move/rename |
| problems & suggested improvements" submitted by a corporate Subversion |
| user, which may be found attached to issue #2282.) |
| |
| -------------------------------------------------------------------------- |
| |
| ========== |
| USE CASE 1 |
| ========== |
| |
| Description |
| |
| During an update, a file modification is merged onto a file move. |
| |
| Current Behavior |
| |
| Developer A modifies Foo.c and commits it to the repository. |
| |
| Developer B has simultaneously moved Foo.c to Bar.c in his working |
| copy. |
| |
| B cannot commit because the working copy is out of date, so B runs 'svn |
| update'. The update will apply A's modifications to Foo.c in the |
| repository to Foo.c in B's working copy. |
| |
| Problems With Current Behavior |
| |
| First problem: |
| |
| A's modification of Foo.c will effectively be reverted by B's new |
| revision. Foo.c will be deleted in the new revision, and Bar.c will be |
| added with the content of the original Foo.c before A's modifications. |
| Hence A will likely get angry with B. |
| |
| Second problem: |
| |
| B is not explicitly warned about reverting A's modification of Foo.c. |
| The only visible warning is that Foo.c is left behind unversioned in |
| B's working copy because it has "local" modifications (which were in |
| fact made by A). This will likely escape B's attention. |
| |
| Diagram of current behavior |
| |
| |
| (edit) |
| wcA -- Foo.c' -------> |
| / | |
| / |commit |
| repos / v |
| -- Foo.c -------------- Foo.c' --------------- Bar.c ---> |
| \ | ^ |
| \ |update |commit |
| \ v | |
| wcB -- +Bar.c ---------- +Bar.c ---- Bar.c ---> |
| (move) -Foo.c -Foo.c' ?Foo.c' (unversioned) |
| |
| |
| Desired behavior |
| |
| When user B updates, A's modifications to Foo.c should be merged into |
| Bar.c. Signal a text conflict if necessary. |
| |
| Foo.c should be deleted from B's working copy. |
| |
| A tree conflict should be signalled to inform B of the new changes |
| to Bar.c, so that B can review the modified Bar.c before committing it. |
| |
| Diagram of desired behaviour |
| |
| |
| (edit) |
| wcA -- Foo.c' -------> |
| / | |
| / |commit |
| repos / v |
| -- Foo.c --------------- Foo.c' ------------------------ Bar.c' ---> |
| \ | ^ ^ |
| \ |update |commit |commit |
| \ v |(fails) | |
| wcB -- +Bar.c ------------ +Bar.c' --------------> |
| (move) -Foo.c -Foo.c ^ |
| | |
| resolved |
| |
| |
| ========== |
| USE CASE 2 |
| ========== |
| |
| Description |
| |
| During an update, a file move is merged onto a file modification. |
| |
| This is essentially the same as Use Case 1, with the difference that |
| this time, B does the edit and A does the move. |
| |
| Current Behavior |
| |
| Developer B modifies Foo.c in his working copy. |
| |
| Developer A has simultaneously moved Foo.c to Bar.c and commits |
| the move to the repository. |
| |
| B cannot commit because his working copy is out of date, so B runs |
| 'svn update'. The next update will add Bar.c (with the same content |
| as the original Foo.c) to B's working copy, and delete Foo.c from |
| B's working copy. Since B made local modifications to Foo.c, |
| it will not be deleted from disk but left behind unversioned. |
| |
| Problems with Current Behavior |
| |
| Developer B may not notice that Foo.c fell out of version control. |
| B's source tree in the working copy likely builds fine because Foo.c |
| is still present on disk. So B may commit an incomplete change set, |
| possibly breaking the tree. Everybody will get angry with B if this |
| happens. |
| |
| Diagram of Current Behaviour |
| |
| |
| (move) |
| wcA -- +Bar.c -------> |
| / -Foo.c | |
| / |commit |
| repos / v |
| -- Foo.c --------------- Bar.c -----------------------> |
| \ | ^ |
| \ |update |commit |
| \ v |(no-op) |
| wcB -- Foo.c' ------------ Bar.c -------> |
| (edit) ?Foo.c' (unversioned) |
| |
| |
| Desired Behavior |
| |
| In B's working copy, the update should add Bar.c and merge the local |
| modifications to Foo.c into Bar.c. Signal a text conflict if necessary. |
| |
| Foo.c should be deleted from B's working copy. |
| |
| A tree conflict should be signaled to inform B that Foo.c has been |
| renamed to Bar.c |
| |
| Diagram of Desired Behaviour |
| |
| |
| (move) |
| wcA -- +Bar.c -------> |
| / -Foo.c | |
| / |commit |
| repos / v |
| -- Foo.c --------------- Bar.c -------------------------- Bar.c'---> |
| \ | ^ ^ |
| \ |update |commit |commit |
| \ v |(fails) | |
| wcB -- Foo.c' ------------+Bar.c' ------------------------> |
| (edit) -Foo.c' ^ |
| | |
| resolved |
| |
| |
| ========== |
| USE CASE 3 |
| ========== |
| |
| Description |
| |
| During an update, a file move is merged onto a conflicting file move. |
| |
| Current Behavior |
| |
| Developer A moves Foo.c to Bar.c and commits the move to the repository. |
| |
| Developer B has moved Foo.c to Bix.c in his working copy. |
| |
| B cannot commit because his working copy is out of date, so B runs |
| 'svn update'. The update will add Bar.c to B's working copy and |
| delete Foo.c from B's working copy (the latter is a no-op). |
| |
| Problems with Current Behavior |
| |
| After B's next commit, the content of the original Foo.c |
| will exist twice in the source tree under two different paths, |
| namely Bar.c and Bix.c, respectively. |
| |
| This may not have been intended. |
| |
| Diagram of Current Behavior |
| |
| |
| (move) |
| wcA -- +Bar.c ------> |
| / -Foo.c | |
| / |commit |
| archive / v |
| -- Foo.c --------------- Bar.c ------------------ Bar.c ---> |
| \ | ^ Bix.c |
| \ |update |commit |
| \ v | |
| wcB -- +Bix.c ---------- +Bix.c -------> |
| (move) -Foo.c Bar.c |
| |
| |
| Desired Behavior |
| |
| A tree conflict should be signaled to inform B of the conflicting rename |
| operation. B can now decide on deleting either file or committing both. |
| |
| Diagram of Desired Behavior |
| |
| |
| (move) |
| wcA -- +Bar.c ------> |
| / -Foo.c | |
| / |commit |
| archive / v |
| -- Foo.c --------------- Bar.c -------------------------- Bar.c --> |
| \ | ^ ^ (or Bix.c, |
| \ |update |commit |commit or both) |
| \ v |(fails) | |
| wcB -- +Bix.c ---------- +Bix.c --------------> |
| (move) -Foo.c Bar.c ^ |
| | |
| resolved |
| |
| |
| ========== |
| USE CASE 4 |
| ========== |
| |
| Description |
| |
| A file modification is merged onto the source of a file move. |
| |
| Current Behavior |
| |
| Developer A modifies Foo.c and commits it to the repository. |
| |
| Developer B moves Foo.c to Bar.c and commits it to the repository. |
| |
| Developer B merges A's new revision into his working copy. The merge |
| will apply A's modification to Foo.c to the Foo.c in B's working |
| copy. |
| |
| Problems With Current Behavior |
| |
| First problem: |
| |
| A's modification of Foo.c will not be merged to B's line of |
| development because the merge skips the absent file. |
| |
| Second problem: |
| |
| B is not explicitly warned about reverting A's modification of Foo.c, |
| except for a "skipped" warning in the output of the merge command, |
| which might not be noticed. |
| |
| Diagram of current behavior |
| |
| |
| (edit) |
| urlA -- Foo.c' ------------------> |
| / (r50) | |
| / | |
| -- Foo.c - |merge -c50 |
| \ |(Foo.c skipped) |
| \ | |
| urlB -- +Bar.c ------------|-----------------> |
| (move) -Foo.c \ | ^ |
| \ | |commit |
| \ v |(no-op) |
| wcB -- Bar.c -- Bar.c ------ --> |
| |
| |
| Desired behavior |
| |
| When user B merges, A's modifications to Foo.c should be merged into |
| Bar.c. Signal a text conflict if necessary. |
| |
| A tree conflict should be signalled to inform B of the new changes |
| to Bar.c, so that B can review the modified Bar.c before committing it. |
| |
| Diagram of desired behaviour |
| |
| |
| (edit) |
| urlA -- Foo.c' ------------------> |
| / (r50) | |
| / | |
| -- Foo.c - |merge -c50 |
| \ |(tree conflict) |
| \ | |
| urlB -- +Bar.c -------------|-------------------- Bar.c' --> |
| (move) -Foo.c \ | ^ ^ |
| \ | |commit |commit |
| \ v |(fails) | |
| wcB -- Bar.c -- Bar.c' ---------------> |
| ^ |
| | |
| resolved |
| |
| |
| ========== |
| USE CASE 5 |
| ========== |
| |
| Description |
| |
| A file move is merged onto a modification of the move-source. |
| |
| This is essentially the same as Use Case 4, with the difference that |
| this time, B does the edit and A does the move. |
| |
| Current Behavior |
| |
| Developer A moves Foo.c to Bar.c and commits it to the repository. |
| |
| Developer B modifies Foo.c and commits it to the repository. |
| |
| Developer B merges A's new revision into his working copy. The merge |
| will add Bar.c (with the same content as the original Foo.c) and |
| will delete B's Foo.c. |
| |
| Problems With Current Behavior |
| |
| First problem: |
| |
| B's has modified Foo.c in the past. This modification will be lost |
| unless B reviews the history of Foo.c and Bar.c at both URLs and |
| corrects the problem (e.g., via 'svn copy'). |
| |
| Diagram of current behavior |
| |
| |
| (move) |
| urlA -- +Bar.c -------------------> |
| / -Foo.c | |
| / (r50) | |
| -- Foo.c - |merge -c50 |
| \ | |
| \ | |
| urlB -- Foo.c' -------------|------------ Bar.c ---> |
| (edit) \ | ^ |
| \ | |commit |
| \ v | |
| wcB -- Foo.c' -- +Bar.c ------> |
| -Foo.c' |
| |
| |
| Desired behavior |
| |
| In B's working copy, the update should add Bar.c and merge the local |
| modifications to Foo.c into Bar.c. Signal a text conflict if necessary. |
| |
| Foo.c should be deleted from B's working copy. |
| |
| A tree conflict should be signaled to inform B that Foo.c has been |
| renamed to Bar.c |
| |
| Diagram of desired behaviour |
| |
| |
| (move) |
| urlA -- +Bar.c -------------------> |
| / -Foo.c | |
| / (r50) | |
| -- Foo.c - |merge -c50 |
| \ |(tree conflict) |
| \ | |
| urlB -- Foo.c' -------------|-------------------- Bar.c'--> |
| (edit) \ | ^ ^ |
| \ | |commit |commit |
| \ v |(fails) | |
| wcB -- Foo.c' -- Bar.c' ---------------> |
| -Foo.c' ^ |
| | |
| resolved |
| |
| |
| ========== |
| USE CASE 6 |
| ========== |
| |
| Description |
| |
| A file move is merged onto a conflicting file move. |
| |
| Current Behavior |
| |
| Developer A moves Foo.c to Bar.c and commits it to the repository. |
| |
| Developer B moves Foo.c to Bix.c and commits it to the repository. |
| |
| Developer B merges A's new revision into his working copy. The merge |
| will add Bar.c with history in B's working copy. |
| |
| Problems With Current Behavior |
| |
| After B's next commit, the content of the original Foo.c will exist |
| twice in the source tree under two different paths (Bar.c and |
| Bix.c). This may not have been intended. |
| |
| Diagram of current behavior |
| |
| |
| (move) |
| urlA -- +Bar.c ------------------> |
| / -Foo.c | |
| / (r50) | |
| -- Foo.c - |merge -c50 |
| \ | |
| \ | |
| urlB -- +Bix.c ------------|---------------- Bix.c ---> |
| (move) -Foo.c \ | ^ Bar.c |
| \ | |commit |
| \ v | |
| wcB -- Bix.c -- Bix.c ----------> |
| +Bar.c |
| |
| |
| Desired behavior |
| |
| A tree conflict should be signaled to inform B of the conflicting |
| rename operation. B can delete either file or commit both. |
| |
| Diagram of desired behaviour |
| |
| |
| (move) |
| urlA -- +Bar.c -----------------> |
| / -Foo.c | |
| / (r50) | |
| -- Foo.c - |merge -c50 |
| \ |(tree conflict) |
| \ | |
| urlB -- +Bix.c ------------|------------------------- Bar.c --> |
| (move) -Foo.c \ | ^ ^ (or Bix.c, |
| \ | |commit |commit or both) |
| \ v |(fails) | |
| wcB -- Bix.c -- Bix.c --------------> |
| +Bar.c ^ |
| | |
| resolved |
| |
