On Tue, Aug 2, 2011 at 12:24 PM, Philip Martin <philip.mar...@wandisco.com> wrote: > Prabhu Gnana Sundar <prabh...@collab.net> writes: > >>> but there are subtree mergeinfo changes that are harder to understand. >>> For subversion/libsvn_subr/svn_temp_serializer.c the change is: >>> >>> Added: svn:mergeinfo >>> Merged >>> /subversion/trunk/subversion/libsvn_subr/svn_temp_serializer.c:r1067687-1072301 >>> >>> which refers to trunk not branches/performance, I don't think that is >>> correct. svn_temp_serializer.c didn't exist on trunk before 1072303, it >>> was created on the performance branch and merged/copied to trunk in >>> 1072303, so that may be what caused the error. >> I tried to replicate the same scenario in my dev box, yet could not >> bring this suspicious mergeinfo >> in place. >> I have even tried to merge the "trunk" instead of the "performance" >> branch. So this seems like some >> sort of manually set property. > > It seems to be reproducible with a 1.7 client: > > $ svn co http://.../trunk@1081135 wc > $ svn merge --record-only http://.../branches/performance@1081135 > -r1067696:1078365 wc > $ svn diff wc/subversion/libsvn_subr/svn_temp_serializer.c > Index: wc/subversion/libsvn_subr/svn_temp_serializer.c > =================================================================== > --- wc/subversion/libsvn_subr/svn_temp_serializer.c (revision 1081135) > +++ wc/subversion/libsvn_subr/svn_temp_serializer.c (working copy) > > Property changes on: wc/subversion/libsvn_subr/svn_temp_serializer.c > ___________________________________________________________________ > Added: svn:mergeinfo > Merged > /subversion/trunk/subversion/libsvn_subr/svn_temp_serializer.c:r1067687-1072301
Here's what happened: Since r880264, --record-only merges actually drive the editor and apply any svn:mergeinfo diffs (see http://svn.haxx.se/dev/archive-2009-09/0520.shtml). Here's the "raw" mergeinfo diff that the --record-only merge tries to apply to svn_temp_serializer.c: C:\SVN\src-trunk-2>svn diff ^^/subversion/branches/performance/subversion/libsvn_subr/svn_temp_serializer.c -r1067696:1078365 Index: svn_temp_serializer.c =================================================================== --- svn_temp_serializer.c (revision 1067696) +++ svn_temp_serializer.c (revision 1078365) @@ -275,11 +275,22 @@ void svn_temp_deserializer__resolve(void *buffer, void **ptr) ... <SNIP> ... Property changes on: svn_temp_serializer.c ___________________________________________________________________ Modified: svn:mergeinfo Merged /subversion/trunk/subversion/libsvn_subr/svn_temp_serializer.c:r1067687-1072519,1072527-1078357 But the resulting mergeinfo is different, as Philip pointed out above: > Property changes on: wc/subversion/libsvn_subr/svn_temp_serializer.c > ___________________________________________________________________ > Added: svn:mergeinfo > Merged > /subversion/trunk/subversion/libsvn_subr/svn_temp_serializer.c:r1067687-1072301 There are three problems here: First: When a --record-only merge adds mergeinfo to a subtree that doesn't have any mergeinfo prior to the merge, it is not updating that subtree with mergeinfo describing the --record-only merge itself. This is very similar to issue #3975 (which I'm presently working on). I filed an issue for this http://subversion.tigris.org/issues/show_bug.cgi?id=3976 ~~~~~ Second: How did ^/subversion/branches/performance/subversion/libsvn_subr/svn_temp_serializer.c end up with mergeinfo that describes non-existent paths? This is almost certainly issue #3669 'inheritance can result in mergeinfo describing nonexistent sources'. You can see this bogus mergeinfo start to accumulate on the performance branch starting in http://svn.apache.org/viewvc?view=revision&revision=993127 when the branch was synced with trunk. Issue #3669 is fixed in 1.7. ~~~~~ Third:How the heck do we end up with this mergeinfo on svn_temp_serializer.c? Property changes on: subversion/libsvn_subr/svn_temp_serializer.c ___________________________________________________________________ Added: svn:mergeinfo Merged /subversion/trunk/subversion/libsvn_subr/svn_temp_serializer.c:r1067687-1072301 What happened is that merge_props_changed starts with: A) ORIGINAL_PROPS: /subversion/trunk/subversion/libsvn_subr/svn_temp_serializer.c:962911-1027198,1039498-1043512 B) PROPCHANGES: /subversion/trunk/subversion/libsvn_subr/svn_temp_serializer.c:962911-1027198,1039498-1043512,1067687-1072519,1072527-1078357 It calls filter_self_referential_mergeinfo which calculates ^/subversion/trunk/subversion/libsvn_subr/svn_temp_serializer.c's history, which as mergeinfo is: C) SELF-REFERENTIAL MERGEINFO: /subversion/branches/integrate-cache-item-serialization/subversion/libsvn_subr/svn_temp_serializer.c:1068724-1068739 /subversion/branches/performance/subversion/libsvn_subr/svn_serializer.c:981090 /subversion/branches/performance/subversion/libsvn_subr/svn_temp_serializer.c:981189 /subversion/trunk/subversion/libsvn_subr/svn_temp_serializer.c:1072302-1081135 It removes the self-referential mergeinfo from the prop changes: D) PROPCHANGES LESS SELF-REFERENTIAL MERGEINFO: /subversion/trunk/subversion/libsvn_subr/svn_temp_serializer.c:962911-1027198,1039498-1043512,1067687-1072301 svn_wc_merge_props3 then applies the difference between D and A (which is what we see in r1081136): E) D LESS A /subversion/trunk/subversion/libsvn_subr/svn_temp_serializer.c:1067687-1072301 Preventing this bogus mergeinfo on the trunk in the first place is a partial solution...not sure how easy it will be to stop propagating it once it's in the repos. Will look into this. Paul
