[SVN-2282] handle file delete/edit/add conflicts: tree changes and conflicts

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: trunk
• Fix Version/s: 1.10.0
• Component/s: libsvn_wc
• Labels: needsdesign tree-conflicts
• Assignee: Unassigned
• Reporter: Ben Collins-Sussman
• Created: 23/Apr/05 13:57
• Updated: 10/Feb/17 13:02
• Resolved: 10/Feb/17 13:02

Description

Subversion has always tried to skirt the issue of tree conflicts.  By "tree conflict", we're talking about 
issues where two users try to do contradictory things to the tree:

   * both users try to add the same path, or
   * one user tries to modify a path, and another tries to delete it

(The case of two users trying to delete the same path isn't a problem, since that's a mergeable tree 
conflict.)

We're currently handling the first sort of tree conflict in a reasonable manner:   'svn up' bails out when 
an existing path blocks its attempt to add a new path, and 'svn commit' will fails if it attempts to add a 
path that already exists in the repository.  There's a since symmetry there.

But in the second type of tree conflict, we're being quite unfriendly:

  A. repos receives deletion;  client updates onto a locally edited file.
                ==> locally edited file silently becomes unversioned (!)
  B. repos recieves file change;  client updates onto a schedule-delete file.
                ==> changes are silently merged into text-base (!)
  C. repos receives deletion;  client commits locally edited file.
                ==> out-of-date commit error.
  D. repos receives file change; client commits deletion of file.
                ==> out-of-date commit error.

Cases (C) and (D) are reasonable, but a whole bunch of users have complained about behaviors (A) and 
(B), especially (A).

Case B seems reckless:  the user is now about to commit the deletion of a file, the latest of which he's 
never even seen.  We tell people that utilities like svnput.c are dangerous for *exactly* this reason, yet 
here we are allowing to happen so easily.

Case A has frustrated users over and over.  The user has 57 edited files, and then runs 'svn update'.  Is 
he really going to notice that *one* file has suddenly gone missing from the changeset?  If 'svn status' 
shows dozens of "M" files and dozens of "?" files (as is often the case), a user just doesn't notice that a 
former 'M' has been converted to '?'.  Their latest edits aren't lost forever, but they're definitely lost in 
the shuffle;  they never get committed, when the user thinks they have been.

The real reason we've not yet done anything about case (A) is that it gets very complex once you start 
talking about directories.  For example, what if the update tries to delete some parent directory of your 
edited file?  Do we set the whole directory into a state of conflict?  How far can the update run before 
bailing out?  Our 1.0 solution was to bail completely on the problem and just "make everything 
unversioned."  But it's time to do better.  As ghudson says, "we shouldn't let the perfect be the enemy 
of the good."  

We can certainly solve a chunk of the problem by marking individual files as (C)onflicted.  It will take a 
bit of design work in libsvn_wc.  What we need to do is expand our concepts of conflict-marking.  Right 
now it always means there's a textual conflict, with three fulltexts left behind, etc.  We need a way to 
mark a file Conflicted when it's schedule-delete but new changes have come from the repository, and a 
way to mark a file Conflicted when it's locally edited, but deleted by the last update.  This will solve 80% 
of users' pain.

Issue Links

• blocks: SVN-2502 'svn diff' fails to show diff for replaced-with-history files
• blocks: SVN-2261 diff on a schedule-replace file shows wrong difference
• blocks: SVN-2685 Move + Merge => lose modifications
• blocks: SVN-2397 schedule add files with conflicts
• blocks: SVN-2543 Inconsistent svn diff after rename
• blocks: SVN-2962 Updating an deleted file should trigger a conflict
• blocks: SVN-563 'svn up' should allow nonconflicting tree merges.
• depends upon: SVN-3150 merge: tree conflicts with directories as victims
• depends upon: SVN-3156 Delete should conflict with delete (at the repos level)
• depends upon: SVN-2892 Directory replacement / node-kind change problems in WC
• depends upon: SVN-3139 merge_tests.py 19 is XFail due to tree conflicts
• depends upon: SVN-3142 merge_tests.py 68 fails on tree-conflicts branch
• depends upon: SVN-3145 svn resolve[d] should be aware of all the different types of conflicts
• depends upon: SVN-3162 use case 5 detection does not check whether victim is obstructed
• depends upon: SVN-3163 check svn_client__wc_delete's behaviour wrt tree conflicts
• depends upon: SVN-3209 Tests XFAIL due to changed tree-conflicts behaviour
• depends upon: SVN-3210 Merge should raise a tree-conflict when deleting a modified directory (UC5-dirs)
• depends upon: SVN-3152 Tree conflicts: check that properties match when checking that text matches.
• depends upon: SVN-3161 Separate obstruction detection from tree conflict detection
• depends upon: SVN-3143 svn commit prints bad error message in case of conflicts
• depends upon: SVN-2908 Improve behavior when tree conflicts are encountered during a merge
• depends upon: SVN-3287 WC entries format number to be bumped now that tree-conflict storage is included
• depends upon: SVN-3144 interactive conflict resolution does not know about tree-conflicts
• is blocked by: SVN-3150 merge: tree conflicts with directories as victims
• is blocked by: SVN-3156 Delete should conflict with delete (at the repos level)
• is blocked by: SVN-2892 Directory replacement / node-kind change problems in WC
• is blocked by: SVN-3139 merge_tests.py 19 is XFail due to tree conflicts
• is blocked by: SVN-3142 merge_tests.py 68 fails on tree-conflicts branch
• is blocked by: SVN-3145 svn resolve[d] should be aware of all the different types of conflicts
• is blocked by: SVN-3162 use case 5 detection does not check whether victim is obstructed
• is blocked by: SVN-3163 check svn_client__wc_delete's behaviour wrt tree conflicts
• is blocked by: SVN-3209 Tests XFAIL due to changed tree-conflicts behaviour
• is blocked by: SVN-3210 Merge should raise a tree-conflict when deleting a modified directory (UC5-dirs)
• is blocked by: SVN-3152 Tree conflicts: check that properties match when checking that text matches.
• is blocked by: SVN-3161 Separate obstruction detection from tree conflict detection
• is blocked by: SVN-3143 svn commit prints bad error message in case of conflicts
• is blocked by: SVN-2908 Improve behavior when tree conflicts are encountered during a merge
• is blocked by: SVN-3287 WC entries format number to be bumped now that tree-conflict storage is included
• is blocked by: SVN-3144 interactive conflict resolution does not know about tree-conflicts
• is depended upon by: SVN-2502 'svn diff' fails to show diff for replaced-with-history files
• is depended upon by: SVN-2261 diff on a schedule-replace file shows wrong difference
• is depended upon by: SVN-2685 Move + Merge => lose modifications
• is depended upon by: SVN-2397 schedule add files with conflicts
• is depended upon by: SVN-2543 Inconsistent svn diff after rename
• is depended upon by: SVN-2962 Updating an deleted file should trigger a conflict
• is depended upon by: SVN-563 'svn up' should allow nonconflicting tree merges.
• is duplicated by: SVN-2797 Update downloads the same files many times