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

Handle mergeinfo when deleting/adding children you don't have access to

    XMLWordPrintableJSON

    Details

      Description

      Spun off from issue #2827
      
      Mergeinfo for a target with missing children is not handled correctly when the
      merge attempts to delete the missing children (or adds children in a way that
      conflicts with the target's depth, e.g. tries to add a dir, when the wc --depth
      is 'files').
      
      To see an example of this problem, apply the attached merge_test.py patch and
      run merge_tests.py:65:"merge_to_sparse_directories" without --cleanup.
      
      For this example we'll look at the WC checked out at --depth files.
      
      >svn st -v merge_tests-1.files
                      9        2 jrandom      merge_tests-1.files
                      9        1 jrandom      merge_tests-1.files\mu
      
      >svn pl -vR merge_tests-1.files
      Properties on 'merge_tests-1.files':
        svn:mergeinfo : /A:1
      
      >set
      URL=file:///C:/SVN/src-trunk/Release/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-1
      
      # Now we merge -r6:10 into the sparse WC.
      #
      # fyi:
      #   r7  - text change to %URL%/A/mu
      #   r8  - Prop add to %URL%/A/D
      #   r9  - Prop add to %URL%/A.
      #   r10 - Delete %URL%/A/C and add %URL%/A/I.
      #
      # r7 and r9 are applied to the WC, but since r8 and r10 effect paths that
      # are not present due to the depth of the WC neither of those changes take
      # place.
      >svn merge %URL%/A merge_tests-1.files -r6:10
      --- Merging r7 through r10:
      U    merge_tests-1.files\mu
      --- Merging r7 through r10:
       U   merge_tests-1.files
      
      # The target of the merge gets non-inheritable mergeinfo and the one
      # child present, file 'mu', gets inheritable mergeinfo.  This is
      # correct to the extent that no missing children of the target should
      # inherit this new mergeinfo...
      >svn pl -vR merge_tests-1.files
      Properties on 'merge_tests-1.files':
        prop:name : propval
        svn:mergeinfo : /A:1,7-10*
      Properties on 'merge_tests-1.files\mu':
        svn:mergeinfo : /A/mu:1,7-10
      
      # ...the problem arises if we bring the missing child we tried to delete
      # back and also permit the child we tried to add to actually be added,
      # a.k.a updating the WC to depth infinity:
      >svn up merge_tests-1.files --depth infinity
      A    merge_tests-1.files\B
      A    merge_tests-1.files\B\lambda
      A    merge_tests-1.files\B\E
      A    merge_tests-1.files\B\E\alpha
      A    merge_tests-1.files\B\E\beta
      A    merge_tests-1.files\B\F
      A    merge_tests-1.files\C
      A    merge_tests-1.files\D
      A    merge_tests-1.files\D\gamma
      A    merge_tests-1.files\D\G
      A    merge_tests-1.files\D\G\pi
      A    merge_tests-1.files\D\G\rho
      A    merge_tests-1.files\D\G\tau
      A    merge_tests-1.files\D\H
      A    merge_tests-1.files\D\H\chi
      A    merge_tests-1.files\D\H\omega
      A    merge_tests-1.files\D\H\psi
      Updated to revision 10.
      
      # The problem is that the mergeinfo on the WC root prevents repeat merges
      # from touching the root.  Changes deeper in the WC, like r8's prop add to
      # 'D' are allowed, but r10's add/delete of the root's children are prevented
      # by our 'avoid repeat merge' logic.
      >svn merge %URL%/A merge_tests-1.files -r6:10
      --- Merging r7 through r10:
      --- Merging r7 through r10:
       U   merge_tests-1.files\D
      
      Within our current merge-tracking solution, I don't see any obvious solution. 
      Of course this seems like a bit of an edge case...but one man's edge case is
      another man's SOP.
      

        Attachments

        1. 2_test.for.issue.2898.2.diff
          2 kB
          Paul Burba
        2. 1_test.for.issue.2898.diff
          2 kB
          Paul Burba

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                pburba Paul Burba
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated: