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
Received on 2011-09-08 18:00:38 CEST