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