On Thu, Sep 8, 2011 at 12:08 PM, Julian Foad <julian.foad_at_wandisco.com> wrote:
> Can I file an issue for this?
What problem(s) is the current behavior causing? I understand your
point, but I hesitate to add merge tracking awareness to diff unless
there is some benefit.
> 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)
Minor semantic nitpick, elision isn't synonymous with mergeinfo
deletion. A svn:mergeinfo property might be deleted outside of merge
tracking (e.g. svn pd).
Which makes me wonder: The current behavior is arguably wrong *if* the
mergeinfo change in question was made by a merge tracking aware merge.
But what if we simply delete a svn:mergeinfo property with 'svn pd'?
Shouldn't the diff show that all the mergeinfo was removed in that
case? Of course there is currently no fool-proof way to differentiate
between a "real" mergetracking merge and manual edits of mergeinfo.
Or do we just assume that all mergeinfo changes originate in merge
tracking aware merges?
> 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:38:05 CEST