On Mon, 2010-01-25 at 11:29 -0500, Paul Burba wrote: > On Mon, Jan 25, 2010 at 9:30 AM, Julian Foad <julian.f...@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....@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....@891675---------------------------@902803----------------------> > | ^ > copied to merge back > | | > V | > 1.6.x-r891...@891677-------------------@902803----------------------> > > > When we attempt to merge 1.6.x-r891...@902803 to 1....@891675, we are > effectively merging the difference between > > ^/subversion/branches/1....@891675 > > and > > ^/subversion/branches/1.6.x-r891...@902803 > > into our 1....@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
