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

RE: 1.7 performance requirements for release

From: Bolstridge, Andrew <andy.bolstridge_at_intergraph.com>
Date: Thu, 9 Dec 2010 13:27:20 -0000

> -----Original Message-----
> From: Blair Zajac [mailto:blair_at_orcaware.com]
> Sent: 09 December 2010 00:45
> To: dev_at_subversion.apache.org
> Subject: 1.7 performance requirements for release
>
[snip]
>
> Do we need to be faster than 1.6 to do a release? Do we want to say,
all
> operations are at least X% faster? It's a much more powerful
statement than
> saying, some operations are faster and some are the same speed.

I'd say all (common) operations need to be faster, or it might as well
just use the old codebase.

The problem is that, even if update was faster but checkout was slower
there would be many people who use checkout a lot more than update and
would complain, so we can't make assumptions about which operation is
more important than another. The best that can be done is to group a
subset of operations that is commonly used and make sure they are all
faster.

>
> I don't feel that strongly about upgrade taking forever, since many
people
> can do a fresh checkout, but I could see this being an issue for
people with
> uncommitted changes in their working copy or changelists.
>

The one-off upgrade isn't a concern. Its once-only after all. Anyone
with uncommitted changes in their WC can either commit them, or copy
them to a different directory and then copy them back over a freshly
checked-out directory. If that's what I had to do with a new version
(that jumped from 1.6 to 1.7) I wouldn't be bothered at all.
Received on 2010-12-09 14:28:08 CET

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.