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

Re: rc1 is DOA. What now?

From: Mark Phippard <markphip_at_gmail.com>
Date: Wed, 24 Aug 2011 10:01:19 -0400

First off, let me just state that I have already said on several occasions I
am OK with rolling an RC2 and since that seems to be the plan I am +1 to it.
 I am not trying to get RC1 released. That said, we could very well wind up
in this same situation again after RC2 is out so I think it is worth
continuing the discussion.

On Wed, Aug 24, 2011 at 4:38 AM, Bert Huijben <bert_at_qqmail.nl> wrote:

> >
> > If 1.7.0 was released with this upgrade bug, you would simply have to
> > wait for a 1.7.x patch release which fixes the bug before upgrading
> > from 1.6.x.
> >
> > This is basically just like any other show stopper you might find
> > during the upgrade to 1.7. Except that you already know about it now :)
> >
> > But I understand your complaints and agree that the problem needs
> > to be fixed in 1.7.x eventually.
> * The average TortoiseSVN user in a corporate environment can't
> upgrade/downgrade its own installation as that as managed via automated
> distribution.
> * TortoiseSVN versions can't be installed side by side.
> (The same problem applies to big multi user installations on shared linux
> installations using plain svn)
> How would you answer an e-mail from your sysadmin that tonight before you
> go
> home you have to remove all locks from all your working copies because
> otherwise tomorrow your working copies are broken?
> (Assuming you have over 40 independent working copies, not counting
> possible
> directory externals, like I had when I worked at TCG)

This is total strawman that you are setting up just so that you can knock it
down. Hyrum has said on numerous occasions that he can and will merge bug
fixes prior to creating the final 1.7. As he pointed out in a recent reply
this was a safe fix that was reviewed. There was nothing that was going to
prevent this from going into 1.7.0. If you disagree with this policy, then
start a new thread for it. There are definitely going to be bugs found in
any RC we release. If we treat all bugs like this we will never release.
 All we have really accomplished is to push this release off another week.

Back to the strawman, you create this scenario of a poor admin that is
rolling out an update to all these workstations. Since when do these people
immediately roll out .0 releases? Since when do these people not do any
testing or investigation of their own? Even if this fix did not make it
into a .0 it would have been in a .1. It also does not factor in that users
can still checkout new working copies etc.

I call this a show stopper; and as I suggested before suggesting these users
> to wait until 1.7.1 is the same as calling this a show stopper.
> And it also breaks the perfect stability track record we had with a
> known-in-advance broken release.

As I said before, I bet it would not take me too long looking through our
open issues in the issue tracker to find a bug that was just as bad as this
one. If we are going to call bugs like this show stoppers it is going to be
difficult to ever get the release out.

Mark Phippard
Received on 2011-08-24 16:01:49 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.