Re: Subversion 1.6.7 on Dec. 16.

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