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

Reverse merges don't work properly with non-inheritable ranges.

    XMLWordPrintableJSON

    Details

      Description

      Merges to targets with non-inheritable ranges, or subtrees with the same, don't
      work if the merge source and range being applied intersect with the
      non-inheritable mergeinfo.
      
      For example, say we merged to a target with switched subtrees and ended up with
      a slew of non-inheritable mergeinfo, something like this (from merge_tests.py 50):
      
      >svn st -v A_COPY
                      8        2 jrandom      A_COPY
                      8        2 jrandom      A_COPY\B
                      8        2 jrandom      A_COPY\B\lambda
                      8        2 jrandom      A_COPY\B\E
                      8        2 jrandom      A_COPY\B\E\alpha
                      8        2 jrandom      A_COPY\B\E\beta
                      8        2 jrandom      A_COPY\B\F
                      8        2 jrandom      A_COPY\mu
                      8        2 jrandom      A_COPY\C
                      8        2 jrandom      A_COPY\D
                      8        2 jrandom      A_COPY\D\gamma
          S           8        2 jrandom      A_COPY\D\G
                      8        2 jrandom      A_COPY\D\G\pi
          S           8        2 jrandom      A_COPY\D\G\rho
                      8        2 jrandom      A_COPY\D\G\tau
                      8        2 jrandom      A_COPY\D\H
                      8        2 jrandom      A_COPY\D\H\chi
                      8        2 jrandom      A_COPY\D\H\omega
          S           8        2 jrandom      A_COPY\D\H\psi
      
      # No mergeinfo yet:
      
      >svn pl -vR A_COPY
      
      # Cherry harvest:
      
      >svn merge %url50%/A A_COPY
      --- Merging r3 through r8 into 'A_COPY\D\G':
      U    A_COPY\D\G\rho
      --- Merging r2 through r8 into 'A_COPY\D\H':
      U    A_COPY\D\H\psi
      U    A_COPY\D\H\omega
      --- Merging r2 through r8 into 'A_COPY':
      U    A_COPY\B\E\beta
      
      # Each switched path and it's siblings get explicit mergeinfo
      # describing the merge.  The parent of each switched path
      # gets the same but with non-inheritable mergeinfo:
      
      >svn pl -vR A_COPY
      Properties on 'A_COPY':
        svn:mergeinfo : /A:2-8
      Properties on 'A_COPY\D':
        svn:mergeinfo : /A/D:2-8*
      Properties on 'A_COPY\D\gamma':
        svn:mergeinfo : /A/D/gamma:2-8
      Properties on 'A_COPY\D\G':
        svn:mergeinfo : /A/D/G:2-8*
      Properties on 'A_COPY\D\G\pi':
        svn:mergeinfo : /A/D/G/pi:2-8
      Properties on 'A_COPY\D\G\rho':
        svn:mergeinfo : /A/D/G/rho:2-8
      Properties on 'A_COPY\D\G\tau':
        svn:mergeinfo : /A/D/G/tau:2-8
      Properties on 'A_COPY\D\H':
        svn:mergeinfo : /A/D/H:2-8*
      Properties on 'A_COPY\D\H\chi':
        svn:mergeinfo : /A/D/H/chi:2-8
      Properties on 'A_COPY\D\H\omega':
        svn:mergeinfo : /A/D/H/omega:2-8
      Properties on 'A_COPY\D\H\psi':
        svn:mergeinfo : /A/D/H/psi:2-8
      
      >svn ci -m ""
      Sending        A_COPY
      Sending        A_COPY\B\E\beta
      Sending        A_COPY\D
      Sending        A_COPY\D\H
      Sending        A_COPY\D\H\chi
      Sending        A_COPY\D\H\omega
      Sending        A_COPY\D\gamma
      Sending        A_COPY\D\G
      Sending        A_COPY\D\G\pi
      Sending        A_COPY\D\G\tau
      Sending        A_COPY\D\H\psi
      Sending        A_COPY\D\G\rho
      Transmitting file data ....
      Committed revision 9.
      
      # Update before going on so no surprises with
      # inheritance or elision:
      
      >svn up
       U   A_COPY_2\D\G\pi
       U   A_COPY_2\D\G\tau
       U   A_COPY_2\D\G
      UU   A_COPY_2\D\H\psi
      UU   A_COPY_3\D\G\rho
      Updated to revision 9.
      
      # Let's say we don't like all that explicit subtree
      # mergeinfo and want to revert the whole mess.  If
      # we reverse merge r8:1 that should get rid of *all*
      # the explicit mergeinfo on A_COPY.  It doesn't even
      # reverse merge everything, let alone set the
      # correct mergeinfo:
      
      >svn merge %url50%/A A_COPY -r8:1
      --- Reverse-merging r8 through r2 into 'A_COPY':
      U    A_COPY\B\E\beta
      
      >svn st A_COPY
       M     A_COPY
      M      A_COPY\B\E\beta
       M     A_COPY\D
       M     A_COPY\D\gamma
       M  S  A_COPY\D\G
       M     A_COPY\D\G\pi
       M  S  A_COPY\D\G\rho
       M     A_COPY\D\G\tau
       M     A_COPY\D\H
       M     A_COPY\D\H\chi
       M     A_COPY\D\H\omega
       M  S  A_COPY\D\H\psi
       
      # Only beta is reverse-merged!?!?  Paths either switched or
      # in a switched subtree, rho, omega, and psi, are not reverse
      # merged.  Worse, the mergeinfo set looks like the full
      # reverse merge did occur, but we end up with empty mergeinfo
      # on the three switched paths:
      
      >svn pl -vR A_COPY
      Properties on 'A_COPY\D\G':
        svn:mergeinfo :
      Properties on 'A_COPY\D\G\rho':
        svn:mergeinfo :
      Properties on 'A_COPY\D\H\psi':
        svn:mergeinfo :
      
      This empty mergeinfo isn't overriding anything and really should elide.  This is
      because of the way we limit elision within sections of a subtree: Merge target T
      has subtree S1 has subtree S2.  We try to elide S1 to T, then S2 to S1 if it
      still exists or T otherwise.  Then finally T to the repos.  But if S2 is
      switched it can't elide up the WC so nothing happens.  We probably need to make
      an exception for switched subtrees and attempt to elide them right to the repos
      as they are completely unrelated to the larger tree in terms of mergeinfo
      inheritance and elision.  If we don't, we can get these cases where we merge a
      range, reverse merge the same range, but end up in a different state than we
      started.
      
      Note: This whole thing has me wondering if this restricted elision is even
      necessary now, I'll look into that after this issue is fixed, I'm *certain*
      there was a reason for this, but now I just don't see it...at any rate, it needs
      to be documented in the code or removed.
      

        Attachments

          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:
                  Resolved: