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 <brane_at_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).
Received on 2009-12-18 04:15:29 CET