Analysis of the 30 test cases (for tree conflicts)

Reposting this to dev_at_subversion.tigris.org (originally posted on
dev_at_svn-tree-conflict.open.collab.net)

--
Hi tree-conflict-crew,
Piet-Hein and I looked at the 30 test cases that Julian defined, and
talking
through it, we found cases missing, and we saw the number of cases blowing
up even further. I therefore tried to come up with a simpler model (see
analysis below).
Tree conflict case analysis:
============================
Let's start by enumerating all the cases:
target \ source | mod add del rep
----------------+-----------------
mod             |  M   X   C   C
add             |  X   C   X   X
del             |  C   X   C   C
rep             |  C   X   C   C
Legend:
M = merge (=text merge for files, dir merge for dirs)
X = can't happen
C = conflict
Notes about this table:
* This table holds for both switch/update and merge.
* This table holds for both files and directories.
Notes about update/switch and merge:
* In case of switch/update, the source is the archive, and target is the
  working copy.
* In case of merge, source is the source branch, and target is the target
  branch (in a working copy).
Notes about the changes mentioned in the table.
* The changes on the source listed in the table are the full set of changes
  to be merged (these changes are by design unique to the source branch,
  thanks to merge tracking).
* The changes on the target listed in the table are the full set of changes
  unique to the target branch, _including_ local modifications in the
working
  copy. (In other words, we need not separate between TCs 9-16 and 17-24.)
From the table we see 9 distinct conflicts:
Desired behaviour (apart from raising the conflict):
1. del onto mod:
   -> Do not do the delete on the working copy
2. rep onto mod:
   -> Do not do the replace on the working copy
3. add onto add:
   -> Do not perform the add from the repo (and keep the add in the working
copy)
4. mod onto del:
   -> file: Put modified file from archive unversioned into WC simplify
merging
   -> dir: Leave scheduled for deletion dir in WC
5. del onto del:
   -> file: delete the file
   -> dir: leave dir scheduled for deletion
6. rep onto del: (Treat as case 4)
   -> file: Put replaced file from archive unversioned into WC simplify
merging
   -> dir: Leave scheduled for deletion dir in WC
7. mod onto rep:
   -> Do not do the modify on the working copy
8. del onto rep:
   -> Do not do the delete on the working copy
9. rep onto rep:
   -> Do not do the replace from the source on the working copy
All in all, there's only two behaviors needed (at level 2: persistent
conflict raising only):
C1. Do nothing besides raising conflict
C2. Put file unversioned into WC (for dirs: do nothing) and raise conflict
This leads to the following (pretty simple) model for tree conflicts:
=====================================================================
Case table:
target \ source | mod add del rep
----------------+-----------------
mod             |  M   X   C1  C1
add             |  X   C1  X   X
del             |  C2  X   C1  C2
rep             |  C1  X   C1  C1
Legend:
M = merge (=text merge for files, dir merge for dirs)
X = can't happen
C1. Do nothing besides raising conflict
C2. Put file unversioned into WC (for dirs: do nothing) and raise conflict
How to detect the conflicts:
* target deleted (i.e. not present in WC, _or_ scheduled for deletion):
   always conflict
* target modified/replaced:
   * Files:
     * "perfect" solution: track back history to find the mods and reps.
     * "ok" solution: (textual) diff of source before del/rep and target.
   * Dirs:
     * "perfect" solution: track back history to find the mods and reps.
     * "ok" solution: diff of source before del/rep and target (as Stefan
       argues, checking the immediate children should be enough).
The "ok" solutions are OK for the short term: they do not catch all cases,
but should drastically diminish the miss rate (besides that, the only cases
missed are those where the files would be interchangeable anyway).
Handling obstructions:
* Unversioned files must never be touched, if a merge/update would need to
  delete, modify, or replace the file: raise a tree conflict.
* All other obstructions should be covered by the case analysis in the
  table.
I hope this helps (the model feels sound to me, but it may be a tad too
simple). I hope it is simple enough to implement as well ...
- Nico