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
Bug
Major