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

wrong notification and bogus mergeinfo during merge which adds dir with mergeinfo

    XMLWordPrintableJSON

    Details

      Description

      A single editor drive merge which adds a subtree with preexisting mergeinfo,
      sets mergeinfo on the added subtree describing the merge, but reports this as
      Mer' G'ed Rather than ' U'pdated.  
      
      For example:
      
      >svn diff ^^/A -r8:10 --summarize
      D      
      file:///C:/SVN/src-trunk/Debug/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-95/A/C
      A      
      file:///C:/SVN/src-trunk/Debug/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-95/A/C_MOVED
       M     
      file:///C:/SVN/src-trunk/Debug/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-95/A
      
      >svn merge ^^/A A_COPY_2 -r8:10
      --- Merging r9 through r10 into 'A_COPY_2':
      A    A_COPY_2\C_MOVED
       U   A_COPY_2
      D    A_COPY_2\C
      --- Recording mergeinfo for merge of r9 through r10 into 'A_COPY_2':
       G   A_COPY_2
      --- Recording mergeinfo for merge of r9 through r10 into 'A_COPY_2\C_MOVED':
       G   A_COPY_2\C_MOVED
       ^^^^^^^^^^^^^^^^^^^^
       C_MOVED should be reported as ' U'pdated.
      
      This occurs because the mergetracking logic (see
      libsvn_client/merge.c:process_children_with_new_mergeinfo) quietly applies the
      added subtree's inherited mergeinfo to it's incoming explicit mergeinfo.  This
      makes sense for subtrees which existed prior to the merge with no mergeinfo,
      since the mergeinfo those paths inherit could easily describe the subtree's
      merge history (...should we add some type of notification for this or would it
      just be a case of implementation details the user doesn't need to know about?).
       For subtrees *added* by the merge though we would ideally skip this, since that
      inherited mergeinfo likely describes non-existent path-revs at best, or other
      lines of history at worst.  However if we were to do this we'd run into issue
      #4269 'subtree mergeinfo can degrade automatic merge performance'.
      
      So in the short term we have a choice: Crippling merge performance *or* odd
      merge notifications and some bogus mergeinfo (which is normal practice should be
      quite harmless).  We've done the latter since 1.5.  Long term, if issue #4269 is
      fixed we can fix this issue too.
      
      Note that this issue applies only to added *directory* subtrees, added files are
      treated inconsistently (which is the reason issue #4269 isn't a far more
      widespread problem).
      

        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: