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.
Paul
Received on 2010-01-25 17:30:31 CET