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

added subtrees with mergeinfo break reintegrate

    XMLWordPrintableJSON

    Details

      Description

      A Collabnet customer (using 1.6.6) is having a problem where they follow the
      standard reintegrate procedure (i.e. sync merge all available revisions from
      trunk to branchX then reintegrate branchX back to trunk) but they get an error
      stating the prior sync merge was not complete, e.g.:
      
        >svn merge ^^/branches/branch02 trunk --reintegrate
        svn: Reintegrate can only be used if revisions 160 through 180 were
        previously merged from %ROOT_URL%/trunk to the reintegrate source, but
        this is not the case:
          branches/branch02/www/index.html
            Missing ranges: /trunk/www/index.html:160-170
      
      ...but of course they *just* did the sync merge.  Further, the "missing" sync
      ranges (e.g. r160-170) are inoperative on the specified subtree.
      
      They demonstrated for me the failed reintegrate merge and a subsequent re-sync
      from trunk to the branch; after which the reintegrate merge still failed.  They
      were working around the situation by doing subtree merges for the missing
      revisions (which were inoperative except for the fact that the set mergeinfo on
      the subtree describing the merge).
      
      This workaround is extremely cumbersome for them because unlike the example
      above, their failed reintegrates feature 10's of subtrees with "missing" sync
      ranges.  This reintegrate failure also happens quite frequently on many of their
      branches.  Needless to say, they are justifiably unhappy.
      
      The customer was doing several things merge-wise that seemed to contribute to
      the problem:
      
        1) They delete their feature branches once they are reintegrated
           and then recreate new feature branches reusing the same name
           as the old branch for subsequent feature work.
      
        2) They do subtree merges (mostly at the file level) and so have
           lots of subtree mergeinfo.
      
        3) They do cyclic cherry pick merges from branches back to trunk.
      
      Neither the customer nor myself could come up with a simple reproduction recipe.
       It wasn't immediately obvious what was wrong beyond the fact that the sync
      merge was not recording itself fully on all the subtrees.
      
      Now I know what you are thinking, "1.5.x-1.6.x always records mergeinfo on every
      subtree right?"  Yes, that is one of the things people hate about merge tracking
      and I worked to fix in 1.7: http://svn.haxx.se/dev/archive-2009-08/0045.shtml
      
      Not so fast...
      
      ...Then it all came back to me, a bit of code I removed from
      libsvn_client/merge.c:get_mergeinfo_walk_cb() while working on the
      subtree-mergeinfo branch might be the culprit:
      http://svn.apache.org/viewvc?view=revision&revision=876855.
      
      That bit of code, dating back to the dawn of merge tracking, ignored subtrees
      with explcit mergeinfo in the merge target if:
      
        A) The explicit mergeinfo didn't naively match the merge source
           (e.g. if you are merging from /trunk to /branch/01 and
           /branch/01/www/index.html has mergeinfo, but that mergeinfo
           doesn't have /trunk/www/index.html:* among its merge sources).
      
        and
      
        B) The path in the source corresponding to the target doesn't
           exist at the start of the requested merge (e.g. continuing
           the above example, if we are merging -r100:200 from /trunk,
           then if /trunk/www/index.html doesn't exist at r100 then
           /branches/01/www/index.html's mergeinfo is ignored).
      
      I sent the customer a patch against 1.6.x@951045 with no functional changes, but
      with some printfs producing output when subtrees were added/dropped from
      consideration by the merge-tracking logic.  Sure enough, dozens of subtrees met
      criteria A and B above and were being dropped from consideration during the sync
      merge and thus never had their mergeinfo updated and caused the subsequent
      reintegrate to fail.
      
      I merged r876855 ^/subversion/branches/subtree-mergeinfo@876855 into
      1.6.x@951045 and sent the resulting patch to the customer to build.  Trying the
      sync merge/reintegrate combo again, the reintegrate failed, but this time only
      one subtree was reported as unsynced (this appears to be be a completely
      different issue).
      
      I still wanted to come up with a reproduction recipe.  That proved a *bit*
      challenging, but I finally have a test that reproduces the problem.  Committing
      that shortly.
      

        Attachments

          Activity

            People

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

              Dates

              • Created:
                Updated:
                Resolved: