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