[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [HEADS-UP] Need more backports to 1.5.0? (was: Re: you're going to kill me, but... [Re: svn commit: r31625 -) branches/1.5.x]

From: David Glasser <glasser_at_davidglasser.net>
Date: Sun, 8 Jun 2008 12:36:03 -0700

On Sun, Jun 8, 2008 at 3:41 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> Also, there's another crash bug already waiting for 1.5.1, namely r31223.
> Which is about "Fix segfault when svn_ra_open3 is passed a bogus URL such
> as 'bogusURL'." This affects 1.4 API users as well, because svn_ra_open2
> calls svn_ra_open3, passing the URL parameter through.
>
> r31223 was scheduled for 1.5.1 and not 1.5.0 by Eric because the crash
> cannot happen with our svn(1) client. Because this is true also for the
> (r31620, r31622) group, I opted for scheduling it for 1.5.1 as well.
> Otherwise I would have nominated it for 1.5.0, because yes, crashing APIs
> are really bad.
>
> If we put either fix into 1.5.0, it does not make much sense to exclude
> the other.

Not that I oppose backporting r31223, but there's a difference between
"crashes instead of throwing an error message on bad input" and
"breaks any program that tries to commit over the repos layer if
there's a start-commit hook".

If people really want to release 1.5.0 without this backport, I'd hope
we'd at least include in big letters in the release announcement "Do
not upgrade if you use this with custom programs that commit directly
to your repository". Wording this well might be harder than just
waiting another week though :-)

--dave

-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-08 21:36:14 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.