The end result of all this discussion appears to be that 1.6.7 can roll as-is, so I will proceed to do so sometime in the next 24 hours.
-Hyrum
On Dec 17, 2009, at 9:26 AM, Philip Martin wrote:
> Paul Burba <ptburba_at_gmail.com> writes:
>
>> Now that we correctly interpret mergeinfo with relative paths
>> (r890993) we actually *consider* mergeinfo with relative source paths.
>> Where Hyrum ran into a problem there was some very dubious mergeinfo
>> on CHANGES in both the reintegrate source and the target:
>>
>> On the target:
>>
>> 1.6.6>svn pg svn:mergeinfo ^^/subversion/branches/1.6.x/CHANGES_at_891108
> [...]
>> /subversion/trunk/CHANGES:836421-837700,875962-876471,876507,876571,880274-880275,880474,880525-880526,881905,884842,886164,886197,888979,889081,889840
>
> I have a an old copy of the r40513 pre-apache repository. It has:
>
> $ svn pg svn:mergeinfo http://localhost:8080/smb/branches/1.6.x-r40452/CHANGES | grep trunk
> /trunk/CHANGES:2-1281,35888-40052,40088,40152,40451-40452
>
>
>> On the source:
>>
>> 1.6.6>svn pg svn:mergeinfo ^^/subversion/branches/1.6.x-r40452/CHANGES_at_891008
> [...]
>> subversion/trunk/CHANGES:836421-837700,872307-876471,876507,876571,880525-880526
>
> $ svn pg svn:mergeinfo http://localhost:8080/smb/branches/1.6.x/CHANGES | grep trunk
> /trunk/CHANGES:2-1281,35888-40052,40088,40152
>
>> What you want to notice here is the mergeinfo
>> 'subverison/trunk/CHANGES:836421-837700', this actually predates the
>> creation of subversion/trunk/CHANGES, which was in r841356. How this
>> got into our repos in the first place is a good question, and one I am
>> trying to track down, see
>> http://mail-archives.apache.org/mod_mbox/subversion-dev/200912.mbox/browser,
>> but I don't think it should impact the decision to roll 1.6.7. There
>> may be another bug here, but since the offending mergeinfo was created
>> a month prior to 1.6.6 we are not dealing with a regression.
>
> And the problem existed the old repository: 2-1281.
>
>> Anyway, onto the "regression". A 1.6.6 client, not realizing that the
>> merge source "subversion/trunk/CHANGES" == "/subversion/trunk/CHANGES"
>> simply ignores the relative pathed mergeinfo. But with r890993 the
>> relative path is interpreted as an absolute path and so the
>> reintegrate code thinks that we have done some merge(s) from trunk to
>> the 1.6.x-r889840 branch, but the code doesn't handle the case where
>> that mergeinfo describes non-existent path-revs, ultimately producing
>> the error that Hyrum saw.
>
> If I reintegrate using
>
> $ svn merge --reintegrate ^/branches/1.6.x-r40452 srcx
>
> then both r890992 and r890993 give
>
> --- Merging differences between repository URLs into 'srcx':
> U srcx/subversion/tests/cmdline/resolved_tests.py
> U srcx/subversion/libsvn_wc/adm_ops.c
> U srcx/CHANGES
> U srcx
>
> So the presence of the dodgy revisions doesn't seem to be a problem
> and the new 1.6.x code will work as well as 1.6.6. It's only when the
> dodgy revisions are combined with the dodgy paths that there is a
> problem.
>
> --
> Philip
Received on 2009-12-17 20:12:20 CET