Paul Burba <ptbu...@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/chan...@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/chan...@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
