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

merge breaks on directory that was previously deleted in source and destination

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: 1.6.x
    • Fix Version/s: 1.10.0
    • Component/s: cmdline client
    • Labels:
      None
    • Environment:

      Linux

      Description

      Assume you have a badDirectory that contains tree conflicts that ordinarily halts a svn merge because 
      of tree conflicts.  
      
      You have the bright idea (born from desperation) that you could kill the badDirectory in source and 
      destination.
      
      But no, it still chokes subversion on the next merge.
      
      Steps to reproduce...
      
      1) svn rm https://svn/repo/trunk/badDirectory -m "kill bad thing"
      2) svn rm https://svn/repo/branches/branch1/badDirectory -m "kill bad thing"
      3) svn co https://svn/repo/branches/branch1
      4) cd branch1
      5) svn merge 1) svn merge https://svn/repo/trunk .
      
                    svn: Attempt to add tree conflict that already exists at 'badDirectory'
                    svn: Error reading spooled REPORT request response
      
      This with a self-built 1.6.x-r38000 from yesterday afternoon.
      I did a search for look-alike issues, but could not see one, hence raising this issue.
      

        Activity

        Hide
        stsp Stefan Sperling added a comment -

        When I run the commands like you described, I get a normal
        tree conflict flagged. There must be something else that triggers
        this bug for you.
        
        Also with 1.6.x-r38000:
        
        $ cd trunk                                                                      
        $ svn rm epsilon                                                                
        svn ci D         epsilon/zeta
        D         epsilon
        $ svn ci -mm
        cd Deleting       epsilon
        .
        Committed revision 3.
        $ cd ../branch/                                        
        $ svn rm epsilon                                       
        D         epsilon/zeta
        D         epsilon
        $ svn ci -mm
        Deleting       epsilon
        
        Committed revision 4.
        $ svn up
        At revision 4.
        $ svn merge ^/trunk
        --- Merging r2 through r4 into '.':
           C epsilon
        Summary of conflicts:
          Tree conflicts: 1
        $ svn st
         M      .
        !     C epsilon
              >   local delete, incoming delete upon merge
        
        

        Show
        stsp Stefan Sperling added a comment - When I run the commands like you described, I get a normal tree conflict flagged. There must be something else that triggers this bug for you. Also with 1.6.x-r38000: $ cd trunk $ svn rm epsilon svn ci D epsilon/zeta D epsilon $ svn ci -mm cd Deleting epsilon . Committed revision 3. $ cd ../branch/ $ svn rm epsilon D epsilon/zeta D epsilon $ svn ci -mm Deleting epsilon Committed revision 4. $ svn up At revision 4. $ svn merge ^/trunk --- Merging r2 through r4 into '.': C epsilon Summary of conflicts: Tree conflicts: 1 $ svn st M . ! C epsilon > local delete, incoming delete upon merge
        Hide
        stsp Stefan Sperling added a comment -

        Sorry the above output has not been cleaned of what I typed ahead.
        

        Show
        stsp Stefan Sperling added a comment - Sorry the above output has not been cleaned of what I typed ahead.
        Hide
        paul Paul Hammant added a comment -

        Yup, our issue had some root cause in tree-conflict territory.
        
        This filing, was as much to illustrate that obliterate is still sorely needed to get folks out of a tricky 
        situation with merges.
        
        'badDirectory' is one that had some (as yet undetermined) combinations of 
        renames/deletes/adds/modifications/replacements.
        
        I.e, I would have preferred to issue 'svn obliterate' instead of 'svn rm'
        

        Show
        paul Paul Hammant added a comment - Yup, our issue had some root cause in tree-conflict territory. This filing, was as much to illustrate that obliterate is still sorely needed to get folks out of a tricky situation with merges. 'badDirectory' is one that had some (as yet undetermined) combinations of renames/deletes/adds/modifications/replacements. I.e, I would have preferred to issue 'svn obliterate' instead of 'svn rm'
        Hide
        stsp Stefan Sperling added a comment -

        Paul, can you please try if this still occurs with the latest code from the
        1.6.x-r38000 branch? I believe I have fixed a bug in r39561 (backported to
        1.6.x-r38000 in r39567) which might have caused this problem for you.
        

        Show
        stsp Stefan Sperling added a comment - Paul, can you please try if this still occurs with the latest code from the 1.6.x-r38000 branch? I believe I have fixed a bug in r39561 (backported to 1.6.x-r38000 in r39567) which might have caused this problem for you.
        Hide
        pburba Paul Burba added a comment -

        Bulk update: For all issues filed before 1.7.0 was tagged and which still have
        the '---' milestone, bump to the 'unscheduled' milestone, as it is exceedingly
        unlikely that any of these are considered release blockers.  See
        http://svn.haxx.se/dev/archive-2013-03/0243.shtml
        

        Show
        pburba Paul Burba added a comment - Bulk update: For all issues filed before 1.7.0 was tagged and which still have the '---' milestone, bump to the 'unscheduled' milestone, as it is exceedingly unlikely that any of these are considered release blockers. See http://svn.haxx.se/dev/archive-2013-03/0243.shtml
        Hide
        stsp Stefan Sperling added a comment -

        Closing this issue as there was no further feedback.

        The new conflict resolver in 1.10 should handle this case.
        https://subversion.apache.org/docs/release-notes/1.10.html#conflict-resolver

        Show
        stsp Stefan Sperling added a comment - Closing this issue as there was no further feedback. The new conflict resolver in 1.10 should handle this case. https://subversion.apache.org/docs/release-notes/1.10.html#conflict-resolver

          People

          • Assignee:
            Unassigned
            Reporter:
            paul Paul Hammant
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development