On Mon, 2010-01-25 at 11:29 -0500, Paul Burba wrote:
> On Mon, Jan 25, 2010 at 9:30 AM, Julian Foad <julian.foad_at_wandisco.com> wrote:
> > The notification "Merging ... r891676 through ..." doesn't match the
> > actual recorded svn:mergeinfo "r891677-...".
> >
> > Full Details
> >
> > I tried a merge in a clean WC of the branch 1.6.x_at_902803, using an
> > r902780M trunk build of svn. (I confirmed with an r902508 trunk build
> > that excludes the recent patch to add notifications when mergeinfo is
> > being recorded. The results are the same except lacking the extra
> > notifications.)
> >
> > [[[
> > $ svn merge --dry-run ^/subversion/branches/1.6.x-r891672/@902803
> > --- Merging r891676 through r902803 into '.':
> > U subversion/tests/cmdline/externals_tests.py
> > U subversion/libsvn_client/commit_util.c
> >
> > $ svn merge ^/subversion/branches/1.6.x-r891672/@902803
> > --- Merging r891676 through r902803 into '.':
> > U subversion/tests/cmdline/externals_tests.py
> > U subversion/libsvn_client/commit_util.c
> > --- Recording mergeinfo for merge of r891676 through r902803 into '.':
> > U .
> >
> > $ svn diff -N
> >
> > Property changes on: .
> > ___________________________________________________________________
> > Modified: svn:mergeinfo
> > Merged /subversion/branches/1.6.x-r891672:r891677-902803
> > ]]]
> >
> > Is that difference in the start revision of the range expected? (The
> > merge saying it's recording "r891676 through ..." versus diff showing
> > that ":r891677-..." was recorded. And a propget confirms the diff.)
> >
> > - Julian
>
> Hi Julian,
>
> (First, a 1000 thanks for running merges with trunk code! We need more of that)
>
> So here is what we have:
>
> ---1.6.x_at_891675---------------------------@902803---------------------->
> | ^
> copied to merge back
> | |
> V |
> 1.6.x-r891672_at_891677-------------------@902803---------------------->
>
>
> When we attempt to merge 1.6.x-r891672_at_902803 to 1.6.x_at_891675, we are
> effectively merging the difference between
>
> ^/subversion/branches/1.6.x_at_891675
>
> and
>
> ^/subversion/branches/1.6.x-r891672_at_902803
>
> into our 1.6.x_at_902803 working copy. Since the "M-N" and "M through N"
> format for merge ranges is inclusive (unlike M:N) we see the
> notifications "r891676 through r902803".
>
> Anyway, we perform the merge and then proceed to record mergeinfo on
> the working copy that describes what we just did, which based on the
> merge would be the addition of this mergeinfo:
>
> /subversion/branches/1.6.x:891676-891677
> /subversion/branches/1.6.x-r891672:891677-902803
>
> But /subversion/branches/1.6.x:891676 describes the working copies own
> history, i.e. is is redundant/self-referential. This self-referential
> mergeinfo is not filtered out before we record the mergeinfo descrbing
> the merge. This is handled in
> libsvn_client/merge.c:filter_natural_history_from_mergeinfo and is
> part of the fix for
> http://subversion.tigris.org/issues/show_bug.cgi?id=3157.
>
> Optimally we should reflect this filtering in the notifications, but
> things get a "bit" more complicated when we are dealing with subtrees
> and I'm uncertain how easy this fix will prove.
Ah... Thanks you very much for the explanation, Paul. I can't say I
followed it well enough to comment further, but it's good to see that
it's at least rational.
- Julian
Received on 2010-01-25 17:47:36 CET