Re: 1.5.0-rc2 up for signing/testing

Mark Phippard wrote:
> On Fri, Apr 11, 2008 at 6:07 PM, Paul Burba <ptburba_at_gmail.com> wrote:
>> On Fri, Apr 11, 2008 at 11:38 AM, Hyrum K. Wright
>> <hyrum_wright_at_mail.utexas.edu> wrote:
>> > Back by popular demand, I'm pleased to announce that Subversion 1.5.0-rc2 is
>> > up for testing and signing. The magic revision is r30541.
>> >
>> > http://orac.ece.utexas.edu/pub/svn/1.5.0-rc2/
>> >
>> > As usual, signatures from full committers back to me, and enthusiastic
>> > tester feedback is welcome. At this point, this candidate is not yet
>> > blessed for wide release, so please don't make it available to people not
>> > interested in test-driving the new release.
>> >
>> > Distro package maintainers, please do NOT include any pre-release builds,
>> > even blessed, into operating system distros. The reasons for not doing so
>> > were very eloquently outlined by Karl in a mail, which is summarized at the
>> > above address.
>> >
>> > The quick version is: we don't guarantee compatibility between the
>> > pre-releases and the final release, so if people install the release
>> > candidate, all their repositories and working copies might break
>> > unrepairably when they upgrade to 1.5.0 proper. We don't want that kind of
>> > bad publicity, and neither do you.
>> >
>> > Happy testing!
>> >
>> > -Hyrum
>>
>> There I was, just about to sign RC2, when Bert found a problem:
>>
>> <Bert> Hmm... I'm getting an access violation with RC 2 in the
>> SharpSvn testset on line 351 of merge.c
>> <Bert> I'm reverse merging HEAD:2 of the collabnet merge repository's
>> trunk back to trunk in that case
>>
>> <markphip> pburba: ^^^
>>
>> <pburba> I see, trying it
>>
>> <Bert> I'm trying to reproduce it with the commandline client..
>>
>> <markphip> that's a diabolical test case
>>
>> <Bert> markphip: I just needed a testcase on that merge variant when I
>> wrote it.. Just reverse everything that has been done or something
>>
>> <pburba> Bert / markphip: still running on the CL...might be a bit...
>>
>> <Bert> The value of the svn_prop_t is NULL, so getting the len value
>> out of it fails
>> <pburba> Gah, oh crap
>>
>> <markphip> pburba's long nightmare continues ...
>>
>> * pburba deflates
>>
>> <Bert> +(svn_prop_t*)(*props)->elts0x081ba130 {name=0x06ee1100
>> "svn:mergeinfo" value=0x00000000 }svn_prop_t *
>>
>> <pburba> Well the fix is easy, but I wonder what that incoming
>> property addition is supposed to mean exactly.
>> <pburba> Oh, removal of the svn:mergeinfo property, of course
>>
>>
>> This can be triggered anytime a merge removes explicit mergeinfo. The
>> "common" use cases where this will be encountered:
>>
>> A) Merges that propogate mergeinfo elision
>>
>> or
>>
>> B) Reverse merging a revision that itself was the result of a merge
>> where that first merge created initial mergeinfo.
>>
>> Fixed on trunk in r30546 and nominated for backport.
>>
>> I think RC3 should be rolled as soon as this can be back-ported.
>>
>> Sorry everyone,
>
> Paul did not explicitly state it, but this was a regression from RC1.
> So we should really halt the RC2 and re-roll. It looks like Paul's
> fix included a new test for this scenario.

I mentioned it in IRC, but I'll post here as well: I'm planning on
rolling RC3 tonight or tomorrow morning.

Thanks to those who have been testing each tarball. Even though they
haven't been officially released, we're still vetting bugs, which is a
Good Thing.

-Hyrum