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

1.7 subtree mergeinfo recording breaks reintegrate

    XMLWordPrintableJSON

    Details

      Description

      Prior to 1.5.5, the merge --reintegrate option would not work if the merge
      source had any subtree mergeinfo.
      
      In 1.5.5 (http://svn.apache.org/viewvc?view=revision&revision=874165) we made
      improvements that allowed reintegrate merges in that case so long as the subtree
      mergeinfo on the source reflected that the same ranges were previously merged
      from the target to the source across the entire source tree, e.g.:
      
        1) Start with a /trunk with explicit subtree mergeino
        2) copy /trunk to /branches/b1
        3) Work continues on /trunk and /branches/b1
        4) sync merge all available revisions from /trunk to /branches/b1
        5) Reintegrate /branches/b1 back to /trunk.
      
      These improvements assumed that all the sync merging previously done to the
      branch was at the *root* of the branch and that all subtrees' mergeinfo was
      updated, regardless of whether the subtree was affected by the merge.
      
      In http://svn.apache.org/viewvc?view=revision&revision=878767 "unrelated"
      improvements were made such that when a merge is performed, only subtrees
      affected by the merge have their mergeinfo updated.  This was not backported but
      will be part of 1.7.
      
      The reintegrate logic needs to take this new behavior into account.  In the
      above use case in step 4, the sync merges no longer record mergeinfo on every
      subtree without exception; if the subtree is unaffected its mergeinfo is not
      altered.  So when the reintegrate merge is attempted in step 5, an error will
      occur, because based strictly on the source's mergeinfo, it appears that the
      source is not completely synced up with the target.
      
      fyi, the error will look something like this:
      
      C:\SVN\trunk-wc>svn merge ^^/branches/feature-branch-3 . --reintegrate
      ..\..\..\subversion\svn\merge-cmd.c:358: (apr_err=195016)
      ..\..\..\subversion\libsvn_client\merge.c:9416: (apr_err=195016)
      svn: Reintegrate can only be used if revisions 40491 through 40561 were
      previously merged from svn:///S.T.O.MIRROR/trunk to the reintegrate source, but
      this is
      not the case:
        branches/feature-branch-3
          Missing ranges: /trunk:40491-40493,40543-40544
        branches/feature-branch-3/subversion
          Missing ranges: /trunk/subversion:40491-40492,40543-40544
        branches/feature-branch-3/subversion/bindings/javahl
          Missing ranges: /trunk/subversion/bindings/javahl:40491-40492,40543
        branches/feature-branch-3/subversion/svn
          Missing ranges: /trunk/subversion/svn:40491,40543-40544
        branches/feature-branch-3/subversion/svn/conflict-callbacks.c
          Missing ranges: /trunk/subversion/svn/conflict-callbacks.c:40543-40544
        branches/feature-branch-3/subversion/tests/cmdline/patch_tests.py
          Missing ranges: /trunk/subversion/tests/cmdline/patch_tests.py:40491-40492,40544
          
      
      It would be desirable to improve the reintegrate logic so that it can determine
      if the "missing" sync merges are inoperative.  If that is the case, it can
      safely allow the reintegrate merge to proceed.  This will also allow the use
      case where all the "sync" merges are done as subtree merges, but effectively all
      the changes have been merged from trunk to the branch.
      
      If we don't do this, reintegrate will return to its pre 1.5.5 status of being
      largely useless when dealing with subtree mergeinfo.  Users will be left only
      with the two-URL merge "workaround", which works perfectly well, but for better
      or worse, people like the simplicity that --reintegrate offers.
      

        Attachments

          Activity

            People

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

              Dates

              • Created:
                Updated:
                Resolved: