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

redundant notifications in single editor drive merge

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: trunk
    • Fix Version/s: 1.8.0
    • Component/s: libsvn_client
    • Labels:
      None

      Description

      As noted by Bert in IRC, when subtree merges have been performed prior to a snyc
      merge, the resulting mergeinfo notifications can be redundant:
      
      <Bert> pburba_: Why do we send those begin lines per 'child with mergeinfo'
      instead of just per revision... That is not one line per editor drive as we
      document it.
      <Bert> We drive the editor per revision(range), but we report an header per
      child with mergeinfo per revision range
      
      <pburba_> Bert: Not totally following, can you point to an example?
      <pburba_> Bert: Wondering if you mean when a subtree needs a different range
      than the target...
      
      <Bert> See the merge tests 96..
      
      (Actually we are talking about mean merge test 69 - ptb)
      
      <pburba_> Bert: Ok, one moment, in the middle of a debug...
      
      <Bert> I: CMD: svn.exe merge -r4:6
      file:///R:/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-69/A
      svn-test-work\working_copies\merge_tests-69\A_COPY --dry-run --config-dir
      R:\subversion\tests\cmdline\svn-test-work\local_tmp\config --password rayjandom
      --no-auth-cache --username jrandom
      <Bert> I: <TIME = 0.031000>
      <Bert> I: --- Merging r5 through r6 into
      'svn-test-work\working_copies\merge_tests-69\A_COPY':
      <Bert> I: U    svn-test-work\working_copies\merge_tests-69\A_COPY\B\E\beta
      <Bert> I: --- Merging r5 through r6 into
      'svn-test-work\working_copies\merge_tests-69\A_COPY\D\H':
      <Bert> I: U    svn-test-work\working_copies\merge_tests-69\A_COPY\D\H\omega
      <Bert> Two paths affected by that range, but below different svn:mergeinfo
      paths.. so different headers.
      <Bert> But only one editor drive
      <Bert> The order in which they are merged is actually random (caused by apr hash
      ordering), so sometimes the dry run result is different than the non-dry run result.
      If you combine that with a merge affecting many files, and the reasonable free
      order of serf you can have the same header many times, with others inbetween.
      
      
      Here's a simple example of the problem, but without identical merge
      notifications (though they are still partially redundant):
      
      Say we have a standard Greek tree with A copied to A_COPY in r1 and a subtree
      merge of r4 made from ^/A/D to A_COPY/D:
      
      >svn mergeinfo ^^/A A_COPY
          youngest common ancestor
          |         last full merge
          |         |        tip of branch
          |         |        |         repository path
      
          1                  7
          |                  |
        -------| |------------         A
           \
            \
             --| |------------         A_COPY
                             |
                             7
      
      >svn mergeinfo --show-revs eligible -R ^^/A A_COPY
      r3
      r5
      r6
      
      vanilla>svn pg svn:mergeinfo -vR A_COPY
      Properties on 'A_COPY\D':
        svn:mergeinfo
          /A/D:4
      
      A subsequent sync merge requires two editor drives to complete, r2-3 and r4-7. 
      This occurs, but the merge notifications are needlessly verbose.  The merge
      output states that it is merging r4-7 into A_COPY then r5-7 into A_COPY/D:
      
      >svn merge ^^/A A_COPY
      --- Merging r2 through r3 into 'A_COPY\D':
      U    A_COPY\D\H\psi
      --- Merging r4 through r7 into 'A_COPY': <---- we notify that we are merging
      U    A_COPY\B\E\beta                           r4-7 into A_COPY here...and
      --- Merging r5 through r7 into 'A_COPY\D': <-- then again some of the same revs
      U    A_COPY\D\H\omega                          into a child of A_COPY here.
      --- Recording mergeinfo for merge of r2 through r7 into 'A_COPY':
       U   A_COPY
      --- Recording mergeinfo for merge of r2 through r7 into 'A_COPY\D':
       U   A_COPY\D
      --- Eliding mergeinfo from 'A_COPY\D':
       U   A_COPY\D
      
      This happens because A_COPY/D has subtree mergeinfo prior to the merge such that
      the subtree doesn't require the same revisions as the merge target.  The
      original intent was to show that that subtree was getting different revisions
      (either more or less) than the target.  But as Bert's example with
      merge_tests.py 69 shows, even when the exact same revisions are being applied to
      the merge target and a given subtree, multiple notifications are made.  Even as
      far as the original intent (i.e. subtrees needing different ranges) this
      probably provides, at best, little or no benefit to users.  At worst it add
      confusion as it appears that some portions of the merge (r5-7 in this example)
      are being merged twice.  As Bert points out, if we have more subtrees with
      mergeinfo, these notifications get progressively more messy, with every subtree
      with mergeinfo affected by the merge getting it's own header.
      
      A more concise set of merge notifications, where any given revision only is only
      notified *once* would be an improvement IMO.  E.g.:
      
      >svn merge ^^/A A_COPY
      --- Merging r2 through r3 into 'A_COPY':
      U    A_COPY\D\H\psi
      --- Merging r5 through r7 into 'A_COPY':
      U    A_COPY\D\H\omega
      U    A_COPY\B\E\beta
      --- Recording mergeinfo for merge of r2 through r7 into 'A_COPY':
       U   A_COPY
      --- Recording mergeinfo for merge of r2 through r7 into 'A_COPY\D':
       U   A_COPY\D
      --- Eliding mergeinfo from 'A_COPY\D':
       U   A_COPY\D
      

        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: