On Thu, Jul 03, 2014 at 04:13:54PM +0100, Julian Foad wrote: > 'svn diff' describes svn:mergeinfo property diffs as "Merged ..." or "Reverse > merged..." rather than using the unified diff output style that it uses for > other property values. > > With Subversion 1.8.9: > > [[[ > $ svn propget -rBASE svn:mergeinfo A; svn propget svn:mergeinfo A > /trunk:10-15,20-25 > /trunk:10-18,20-25 > > $ svn diff > Index: A > =================================================================== > --- A (revision 1) > +++ A (working copy) > > Property changes on: A > ___________________________________________________________________ > Modified: svn:mergeinfo > Merged /trunk:r16-18 > ]]] > > With Subversion trunk the last part of the output changes to: > > [[[ > Modified: svn:mergeinfo > ## -0,0 +0,1 ## > Merged /trunk:r16-18 > ]]] > > The line beginning with "##" has crept in, where it was previously omitted. > > I assume this is unintentional, as the information in it is not useful. > > - Julian
There is a rational outlined in the commit which introduced this change. ------------------------------------------------------------------------ r1598092 | stsp | 2014-05-28 20:08:52 +0200 (Wed, 28 May 2014) | 14 lines For issue #3747, 'svn patch' support of svn:mergeinfo, make it possible to parse svn:mergeinfo diffs regardless of i18n. * subversion/libsvn_diff/util.c (display_mergeinfo_diff): Print a hunk header line for mergeinfo diffs. The header indicates the number of reverse-merges and forward-merges in the diff. Before this change, this information was only printed as part of output which is translated for i18n. This made it impossible to reliably parse svn:mergeinfo diffs from patch files. Futher changes to the diff parser and svn patch are coming soon. * subversion/tests/cmdline/merge_tests.py (merge_in_new_file_and_diff): Adjust expected output. ------------------------------------------------------------------------ The idea to make 'svn patch' support mergeinfo was later vetoed. I think the information is still valuable to diff parsers, and our diff parser was also changed to look for it (though svn patch doesn't use it). I don't see a problem with adding this feature but if someone can show that it arguably introduces a huge problem I would revert it.
