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 <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
