On Tue, Aug 2, 2011 at 12:24 PM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> Prabhu Gnana Sundar <prabhugs_at_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
Received on 2011-08-02 22:31:25 CEST