Uploaded image for project: 'Subversion'
  1. Subversion
  2. SVN-2282

handle file delete/edit/add conflicts: tree changes and conflicts

    Details

      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.
      

      1. 1_tree-conflicts-use-cases-svn-1.4.ppt
        227 kB
        C. Michael Pilato
      2. 2_tree-conflicts-use-cases-svn-1.4.pdf
        94 kB
        Julian Foad
      3. 3_requirements-specification-treeconflict.pdf
        766 kB
        Stefan Sperling

        Issue Links

          Activity

          Hide
          kfogel Karl Fogel added a comment -

          If we just try to handle the file case, this seems doable for 1.3-consider.
          

          Show
          kfogel Karl Fogel added a comment - If we just try to handle the file case, this seems doable for 1.3-consider.
          Hide
          ehuelsmann Erik Huelsmann added a comment -

          I think tree conflicts are much broader than this: what should we do when
          receiving updates to a locally-replaced file? Currently we just merge the
          changes into the new file, which is IMO *very* wrong. (Goes against the intent
          of the user to replace the file and break history.)
          
          BTW: since it's not addressed now, it's not 1.3-consider anymore. Moving into
          1.4-consider.
          

          Show
          ehuelsmann Erik Huelsmann added a comment - I think tree conflicts are much broader than this: what should we do when receiving updates to a locally-replaced file? Currently we just merge the changes into the new file, which is IMO *very* wrong. (Goes against the intent of the user to replace the file and break history.) BTW: since it's not addressed now, it's not 1.3-consider anymore. Moving into 1.4-consider.
          Hide
          subversion-importer Subversion Importer added a comment -

          I understand that it quickly gets nasty to find a perfect solution, but IMHO
          almost any behaviour is better than the status quo of silently ignoring it.
          
          I can think of some quick solutions that are by far not perfect, but a betterment:
          
          1) Simply delete the file in case A.
             Seems redical, but it is what I had expected.
          2) Display some warning during the update. Maybe in combination with 1).
          3) Mock case A. as a file merge conflict with an empty file.
          
          

          Original comment by rd

          Show
          subversion-importer Subversion Importer added a comment - I understand that it quickly gets nasty to find a perfect solution, but IMHO almost any behaviour is better than the status quo of silently ignoring it. I can think of some quick solutions that are by far not perfect, but a betterment: 1) Simply delete the file in case A. Seems redical, but it is what I had expected. 2) Display some warning during the update. Maybe in combination with 1). 3) Mock case A. as a file merge conflict with an empty file. Original comment by rd
          Hide
          ehuelsmann Erik Huelsmann added a comment -

          Given that this issue needs design discussion and that nothing happened for 1.4,
          moving into 1.5-consider.
          

          Show
          ehuelsmann Erik Huelsmann added a comment - Given that this issue needs design discussion and that nothing happened for 1.4, moving into 1.5-consider.
          Hide
          ehuelsmann Erik Huelsmann added a comment -

          Setting needsdesign keyword.
          

          Show
          ehuelsmann Erik Huelsmann added a comment - Setting needsdesign keyword.
          Hide
          ehuelsmann Erik Huelsmann added a comment -

          Clarify summary.
          

          Show
          ehuelsmann Erik Huelsmann added a comment - Clarify summary.
          Hide
          dlr Daniel Rall added a comment -

          Erik pointed out that the notification behavior for issue 2403 may need to be
          changed to correspond to whatever is decided for this issue.
          

          Show
          dlr Daniel Rall added a comment - Erik pointed out that the notification behavior for issue 2403 may need to be changed to correspond to whatever is decided for this issue.
          Hide
          dlr Daniel Rall added a comment -

          Issue 2397 is related.
          

          Show
          dlr Daniel Rall added a comment - Issue 2397 is related.
          Hide
          ehuelsmann Erik Huelsmann added a comment -

          Moving to 1.6-consider. There's too much in 1.5 to resolve this issue (which
          still needs design!)
          
          

          Show
          ehuelsmann Erik Huelsmann added a comment - Moving to 1.6-consider. There's too much in 1.5 to resolve this issue (which still needs design!)
          Hide
          cmpilato C. Michael Pilato added a comment -

          duck ... duck ... duck ... GOOSE!
          

          Show
          cmpilato C. Michael Pilato added a comment - duck ... duck ... duck ... GOOSE!
          Hide
          cmpilato C. Michael Pilato added a comment -

          Added notes/tree-conflicts.txt for working through use-cases
          [http://svn.collab.net/viewvc/svn/trunk/notes/tree-conflicts.txt?revision=25036&view=markup]
          

          Show
          cmpilato C. Michael Pilato added a comment - Added notes/tree-conflicts.txt for working through use-cases [http://svn.collab.net/viewvc/svn/trunk/notes/tree-conflicts.txt?revision=25036&view=markup]
          Hide
          cmpilato C. Michael Pilato added a comment -

          CollabNet services reports the following prioritized list of tree conflicts
          use-cases (where priority is provided by customers particularly suffering from
          this class of Subversion problem):
          
          1. Merging a modification onto a deletion yields but a "Skipped missing
             target" warning.
          
          2. Merging a modification onto a rename "loses" modification, leaving
             modified path as unversioned file in the working copy.  ("Losing" as 
             in it no longer appears in the HEAD revision.  Of course it still remains
             in earlier revisions.)
          
          3. Merging a deletion onto a modification "loses" modification in the
             target without warning.
          
          4. Merging a rename onto a modification "loses" modification, leaving
             modified path as unversioned file in the working copy.
          
          5. Merging a rename onto another rename leaves both targets in the
             repository without warning. 
          
          
          

          Show
          cmpilato C. Michael Pilato added a comment - CollabNet services reports the following prioritized list of tree conflicts use-cases (where priority is provided by customers particularly suffering from this class of Subversion problem): 1. Merging a modification onto a deletion yields but a "Skipped missing target" warning. 2. Merging a modification onto a rename "loses" modification, leaving modified path as unversioned file in the working copy. ("Losing" as in it no longer appears in the HEAD revision. Of course it still remains in earlier revisions.) 3. Merging a deletion onto a modification "loses" modification in the target without warning. 4. Merging a rename onto a modification "loses" modification, leaving modified path as unversioned file in the working copy. 5. Merging a rename onto another rename leaves both targets in the repository without warning.
          Hide
          sussman Ben Collins-Sussman added a comment -

          *** Issue 2797 has been marked as a duplicate of this issue. ***
          

          Show
          sussman Ben Collins-Sussman added a comment - *** Issue 2797 has been marked as a duplicate of this issue. ***
          Hide
          cmpilato C. Michael Pilato added a comment -

          Attachment 1_tree-conflicts-use-cases-svn-1.4.ppt has been added with description: Some use-cases around this problem, demonstrated graphically

          Show
          cmpilato C. Michael Pilato added a comment - Attachment 1_tree-conflicts-use-cases-svn-1.4.ppt has been added with description: Some use-cases around this problem, demonstrated graphically
          Hide
          cmpilato C. Michael Pilato added a comment -

          Created an attachment (id=770)
          Some use-cases around this problem, demonstrated graphically
          
          

          Show
          cmpilato C. Michael Pilato added a comment - Created an attachment (id=770) Some use-cases around this problem, demonstrated graphically
          Hide
          julianfoad Julian Foad added a comment -

          Attachment 2_tree-conflicts-use-cases-svn-1.4.pdf has been added with description: Some use-cases around this problem, demonstrated graphically [tree-conflicts-use-cases-svn-1.4.ppt converted to PDF]

          Show
          julianfoad Julian Foad added a comment - Attachment 2_tree-conflicts-use-cases-svn-1.4.pdf has been added with description: Some use-cases around this problem, demonstrated graphically [tree-conflicts-use-cases-svn-1.4.ppt converted to PDF]
          Hide
          julianfoad Julian Foad added a comment -

          Created an attachment (id=807)
          Some use-cases around this problem, demonstrated graphically [tree-conflicts-use-cases-svn-1.4.ppt converted to PDF]
          
          

          Show
          julianfoad Julian Foad added a comment - Created an attachment (id=807) Some use-cases around this problem, demonstrated graphically [tree-conflicts-use-cases-svn-1.4.ppt converted to PDF]
          Hide
          stsp Stefan Sperling added a comment -

          Attachment 3_requirements-specification-treeconflict.pdf has been added with description: Here is the document that was actually used as the basis for notes/treeconflicts/use-cases.txt. I wasn't aware that the other document linked here is a different one which has no use case numbering. Sorry for the confusion.

          Show
          stsp Stefan Sperling added a comment - Attachment 3_requirements-specification-treeconflict.pdf has been added with description: Here is the document that was actually used as the basis for notes/treeconflicts/use-cases.txt. I wasn't aware that the other document linked here is a different one which has no use case numbering. Sorry for the confusion.
          Hide
          stsp Stefan Sperling added a comment -

          Created an attachment (id=808)
          Here is the document that was actually used as the basis for notes/treeconflicts/use-cases.txt. I wasn't aware that the other document linked here is a different one which has no use case numbering. Sorry for the confusion.
          
          

          Show
          stsp Stefan Sperling added a comment - Created an attachment (id=808) Here is the document that was actually used as the basis for notes/treeconflicts/use-cases.txt. I wasn't aware that the other document linked here is a different one which has no use case numbering. Sorry for the confusion.
          Hide
          hwright Hyrum Wright added a comment -

          Post-1.6 issue sweep.  Since 1.7 is already shaping up to be a large release,
          move to 1.8-consider.
          

          Show
          hwright Hyrum Wright added a comment - Post-1.6 issue sweep. Since 1.7 is already shaping up to be a large release, move to 1.8-consider.
          Hide
          cmpilato C. Michael Pilato added a comment -

          1.8.0 is stabilizing for release right now.  As such, the branch is no longer
          open to non-defect-related issue work.  Bumping FEATURE and ENHANCEMENT issues
          scheduled for 1.8-consider to 1.9-consider instead.
          

          Show
          cmpilato C. Michael Pilato added a comment - 1.8.0 is stabilizing for release right now. As such, the branch is no longer open to non-defect-related issue work. Bumping FEATURE and ENHANCEMENT issues scheduled for 1.8-consider to 1.9-consider instead.
          Hide
          rhuijben Bert Huijben added a comment -

          As far as I can tell the original issue reported here is fixed as we properly 
          handle deletes during merges for tree conflict handling since 1.8.0.
          
          But then several 'usecases' were added for moved files, but no real issue or 
          idea what to fix.
          
          Can we close this issue now?
          Or will it remain open forever/until somebody converts this to one or more real 
          issues?
          
          
          Adding cmpilato to the cc as he added the usecases.
          

          Show
          rhuijben Bert Huijben added a comment - As far as I can tell the original issue reported here is fixed as we properly handle deletes during merges for tree conflict handling since 1.8.0. But then several 'usecases' were added for moved files, but no real issue or idea what to fix. Can we close this issue now? Or will it remain open forever/until somebody converts this to one or more real issues? Adding cmpilato to the cc as he added the usecases.
          Hide
          cmpilato C. Michael Pilato added a comment -

          The original problem was about add/modify/delete tree conflicts.  The "new"
          cases I added were just additional ways to trigger those same types of general
          tree conflicts, right?
          
          Over time this issue has become the parent issue for a slew of dependent
          tree-conflict-related child issues.  I think it's fine to leave this issue open
          as long as we have known shortcomings in our design for handling tree conflicts.
           When the design is complete and implemented, this can be closed.  (Maybe that's
          now?)
          
          Any subsequently discovered bugs needn't be associated with this issue, of course.
          

          Show
          cmpilato C. Michael Pilato added a comment - The original problem was about add/modify/delete tree conflicts. The "new" cases I added were just additional ways to trigger those same types of general tree conflicts, right? Over time this issue has become the parent issue for a slew of dependent tree-conflict-related child issues. I think it's fine to leave this issue open as long as we have known shortcomings in our design for handling tree conflicts. When the design is complete and implemented, this can be closed. (Maybe that's now?) Any subsequently discovered bugs needn't be associated with this issue, of course.
          Hide
          julianfoad Julian Foad added a comment -

          Bump all open 1.9-consider issues to 1.10-consider, now that they have missed
          the boat for 1.9.
          

          Show
          julianfoad Julian Foad added a comment - Bump all open 1.9-consider issues to 1.10-consider, now that they have missed the boat for 1.9.
          Hide
          stsp Stefan Sperling added a comment -

          I am declaring this issue as fixed by the new conflict resolver in 1.10.
          https://subversion.apache.org/docs/release-notes/1.10.html#conflict-resolver

          We are of course still happy about new bug reports for more specific issues with tree conflicts. Please send any such bug reports to the users@ list for consideration.

          Show
          stsp Stefan Sperling added a comment - I am declaring this issue as fixed by the new conflict resolver in 1.10. https://subversion.apache.org/docs/release-notes/1.10.html#conflict-resolver We are of course still happy about new bug reports for more specific issues with tree conflicts. Please send any such bug reports to the users@ list for consideration.

            People

            • Assignee:
              Unassigned
              Reporter:
              sussman Ben Collins-Sussman
            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development