You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Paul Burba <pt...@gmail.com> on 2010/01/25 16:29:55 UTC
Re: svn merge - start revision off by one, and repeat merge is not a
no-op
On Mon, Jan 25, 2010 at 9:30 AM, Julian Foad <ju...@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@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@891675---------------------------@902803---------------------->
| ^
copied to merge back
| |
V |
1.6.x-r891672@891677-------------------@902803---------------------->
When we attempt to merge 1.6.x-r891672@902803 to 1.6.x@891675, we are
effectively merging the difference between
^/subversion/branches/1.6.x@891675
and
^/subversion/branches/1.6.x-r891672@902803
into our 1.6.x@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.
Paul
Re: svn merge - start revision off by one, and repeat merge is not
a no-op
Posted by Julian Foad <ju...@btopenworld.com>.
On Mon, 2010-01-25 at 11:29 -0500, Paul Burba wrote:
> On Mon, Jan 25, 2010 at 9:30 AM, Julian Foad <ju...@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@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@891675---------------------------@902803---------------------->
> | ^
> copied to merge back
> | |
> V |
> 1.6.x-r891672@891677-------------------@902803---------------------->
>
>
> When we attempt to merge 1.6.x-r891672@902803 to 1.6.x@891675, we are
> effectively merging the difference between
>
> ^/subversion/branches/1.6.x@891675
>
> and
>
> ^/subversion/branches/1.6.x-r891672@902803
>
> into our 1.6.x@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