On Dec 17, 2009, at 9:10 PM, Branko Čibej wrote: > Paul Burba wrote: >> On Thu, Dec 17, 2009 at 5:53 PM, Branko Čibej <br...@xbc.nu> wrote: >> >>> Paul Burba wrote: >>> >>>> Regardless, I don't think this is a true regression, just a >>>> new bug, and as such, not something that should hold up 1.6.7. >>>> >>>> >>> Sorry, what? Subversion will suddenly error out where it previously did >>> not. No matter /how/ that mergeinfo got into the repository, if we don't >>> fix this before releasing 1.6.7, we'll likely get a whole bunch of error >>> reports. Telling people that "it's not really a bug" isn't going to be >>> very productive, given that it effectively stops them from using svn >>> merge in this situation. >>> >>> Can you be sure that the circumstances that lead to this error are rare >>> enough to address in 1.6.8? >>> >> >> Hi Brane, >> >> I haven't explained this clearly, sorry. What has happened here is a >> semi-complicated dance among several issues. >> >> Let me try to explain again: >> >> The reintegrate bug Hyrum encountered is not IMO a regression because >> it *only* worked in 1.6.6 because another bug hid it. >> >> That other bug is issue #3547, which converted all the mergeinfo in >> our repository from absolute paths to relative paths. The mergeinfo >> APIs don't expect relative source paths in mergeinfo, so when it is >> encountered the results are unpredictable (and usually wrong). >> >> In r890993 I made fixes so the relative pathed mergeinfo are >> interpreted as absolute, and so the various svn_mergeinfo_* APIs don't >> choke on the relative paths. This was nominated and backported to >> 1.6.7. >> >> Along comes Hyrum, who, using the latest 1.6.7 with r890993 included, >> tries to reintegrate a backport branch to 1.6.x. It fails, a bug! >> >> I try the same merge with 1.6.6 and it works. Regression right? >> Actually no. It only worked because without the r890993 fix, the >> relative pathed mergeinfo caused by issue #3547 was essentially >> invisible to 1.6.6. It was just dumb luck that it actually >> *prevented* an error. It most cases it would cause errors, as we >> discussed here: http://svn.haxx.se/dev/archive-2009-12/0222.shtml. >> >> ~~~~~ >> >> This may all be moot because I fixed the bug in r892085 and nominated >> this for backport to 1.6.7. I also nominated a test which reproduces >> the bug Hyrum found. This test fails across the board on trunk, >> 1.6.x, and 1.6.6 without the the r892085 fix in place. >> >> I hope that makes things clearer. If not let me know or ping me in >> IRC tomorrow. >> >> Thanks, >> > > Oh, I think I see. So the no-leading-slash in svnadmin load caused some > merge info to be ignored, and when you made the merge logic more > flexible WRT the svn:mergeinfo format, this new bug (not ignoring > irrelevant revisions in svn:mergeinfo?) raised its head. > > OK ... I gather from other posts that we don't really know when this > invalid mergeinfo got into the repository, but we can assume that it was > caused by another bug (possibly even in 1.5) which has hopefully since > been fixed.
Paul may be able to correct me here, but I think the bug which caused the invalid mergeinfo was only fixed recently, and has been merged to 1.6.x for the 1.6.7 release. > The question remains, though, can this situation really only be > reproduced with the complex chain of events we saw here? In other words, > if we had not migrated the repository to svn.apache.org and still had > invalid mergeinfo in the repository -- would not the merge have failed > even without your recent change in mergeinfo handling? > > I'm trying to wrap my head around this because it doesn't seem > reasonable that irrelevant revisions in mergeinfo would only cause > problems in combination with your changes. Because if that's the case, > then there's either a bug in your "flexibilification" of mergeinfo > paths, or there's a more fundamental bug in mergeinfo processing ... > sorry if all this isn't crystal clear, but this is a bit of a muddle. :) > > To illustrate what I'm getting at ... say a user has a file ^/foo in her > repository that was created in r10. He creates a branch, "svn cp ^/foo > ^/bar" and creates r11. in r12, she modifies ^/foo, and in r13 merges > the change to ^/bar. One would expect ^/bar's mergeinfo to be: > /foo:10-12, yes? Now let's imagine for a moment that for some reason > this was all done with a broken client/server combo, and the actual > mergeinfo is: /foo:2-12. Would Hyrum's reintegrate merge fail in the > same way in this case? If not, why not? Reguardless of how frequently this problem exhibits itself, Paul claims* to have fixed it in r892085, and should that prove true, the problem of frequency is moot. FWIW, I haven't yet rolled the 1.6.7 tarball, so we can straighten this all out tomorrow and possibly roll then. -Hyrum * - Not that I doubt Paul's ability to fix this bug, I just haven't seen any review on it yet (and haven't done so myself).
