Can I file an issue for this? Philip said the server makes (or used to make?) the same mistake internally when processing mergeinfo - presumably in the guts of the ra_get_mergeinfo2 API?
I assume the deletion (elision) of a mergeinfo prop would generate an all-revs-unmerged diff output, but haven't tested that. - Julian On Thu, 2011-09-08 at 16:59 +0100, Julian Foad wrote: > If Subversion creates subtree mergeinfo on a path that previously didn't > have any, then "svn diff" incorrectly shows all the source revs in that > mergeinfo as newly "merged". > > In a Subversion trunk WC, using 1.7.0-rc2: > > $ svn merge -c 1000000 ^/subversion/branches/1.6.x/INSTALL INSTALL > --- Merging r1000000 into 'INSTALL': > U INSTALL > --- Recording mergeinfo for merge of r1000000 into 'INSTALL': > G INSTALL > > [Note that r1000000 is a no-op on trunk, so in fact no content change > was made despite the 'U' marker.] > > $ svn diff INSTALL > Index: INSTALL > =================================================================== > --- INSTALL (revision 1166027) > +++ INSTALL (working copy) > > Property changes on: INSTALL > ___________________________________________________________________ > Added: svn:mergeinfo > Merged /subversion/branches/atomic-revprop/INSTALL:r965046-1000689 > Merged /subversion/branches/diff-callbacks3/INSTALL:r870059-870761 > Merged /subversion/branches/bdb-reverse-deltas/INSTALL:r872050-872529 > Merged /subversion/branches/double-delete/INSTALL:r870511-872970 > [...] > > This is wrong. The property certainly was added, but that does not mean > all those revisions were merged. The expected output is something like: > > [...] > Added: svn:mergeinfo > Merged /subversion/branches/1.6.x/INSTALL:r1000000 > > > The bug is that "svn diff" shows a mergeinfo diff assuming that the > previous merginfo was an explicit empty set of mergeinfo, but it wasn't, > it was inherited mergeinfo. > > - Julian > >
