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
