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

Re: Speeding up workspace

From: Talden <talden_at_gmail.com>
Date: Wed, 18 Feb 2009 15:18:44 +1300

> There are a number of new features in 1.6, some of which are user-
> visible, others which are not as visible. The Subversion community is
> trying hard to do more frequent minor releases, in an effort to cut
> down on the amount of new stuff in each release. This makes
> development more manageable, decreases the new testing surface area,
> and hopefully gives users access to more features more frequently.
> Compared to the almost 2-year cycle for 1.5, 9 months for 1.6 is quite
> rapid!

Hyrum, this is the bit that gets me. The WC-NG effort is fantastic
but is real, true effort with a lot of testing. If the 1.6 cycle is
considered fast and 1.6 is not yet final then we're talking 9 months
(I saw 6 mentioned, that sounds hopeful) to get this improvement.

Can we not have WC-NG in 1.8 and get a 1.7 ASAP after 1.6 that has a
fix for this locking performance issue.

It seems we're either holding off just because the release number
(1.7) has already been assigned for WC-NG or because we're holding
back this fix to make the 1.6 -> WC-NG performance comparison look

On my laptop, defragged and as disk-cached as possible, an empty
update from a LAN server takes me 1m30s with svn://... Doing an pull
into a branch-with-working-tree in Bazaar takes 30s - and Bazaar is
considered one of the slower DVCS tools. In nine months there might
be a few users to show that nice and shiny WC-NG to.

Is there really no way this number of voices here can't shift the
project plan and get an interim fix in - redundant once WC-NG arrives
(which I am excited about, don't you worry).

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-18 03:19:49 CET

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

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