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

Re: Version of Subversion on svn.collab.net

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: 2004-10-11 23:16:12 CEST

--On Sunday, October 10, 2004 10:03 AM -0500 "C. Michael Pilato"
<cmpilato@collab.net> wrote:

> "C. Michael Pilato" <cmpilato@collab.net> writes:
>> If a problem is found in one of our release candidates or final
>> releases that is so bad that we would be tempted to upgrade
>> svn.collab.net, then that problem is bad enough to require us to
>> roll a new release candidate or bugfix release, at which time our
>> server can be upgraded accordingly.
> For example, this ra->get_dirs() performance death that's living in
> our 1.1.0 release. Had I upgraded svn.collab.net to 1.1.0, we'd all
> be suffering this awful performance. And why haven't we rolled 1.1.1
> with this fix?

No. This is the perfect case of why we want to eat our dog food. In a
perfect world, we would have deployed rc4 to svn.collab.net for a few days.
Then, we likely would have spotted this regression and then fixed it
instead of including the regression in 1.1.0.

We wrote the code, so we sure better be able to cope with the latest
versions! We *want* to see these problems before our other users do.
svn.collab.net has the highest percentage of users that'll be able to fix
any problem in Subversion. It's unlikely any other public repository does.

I really don't like the implication that the people who wrote the code
don't trust it while telling everyone else to upgrade. That's bad. --

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 11 23:16:27 2004

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.