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

RE: Subversion working copy speed

From: Christopher Ness <chris_at_nesser.org>
Date: 2005-08-24 20:30:08 CEST

On Wed, 2005-08-24 at 11:46 -0600, Robert Cronk wrote:
> > Robert Cronk wrote:
> > > Linux Client Stats
> > > Pentium 3 860 MHz
> > > 256 MB RAM, 512 MB swap
> > > Ext3, 30 GB of 38 GB used
> > > Fedora Core 3

<snip />

> Certainly throwing more RAM at it will speed things up, but I was hoping
> for a solution involving some clever thoughts and ideas about how to
> minimize disk accesses on the client when doing update and status
> operations. I would very much not like our developers' first experience
> with subversion to involve deciding on whether or not to go to the
> restroom while the status finishes. :) That would not be a good first
> impression. Do you have any ideas other than throwing more hardware at
> it? I, for one, am willing to work around a 1 minute status and update
> because I already know of the other amazing advantages of SVN, but a
> newbie to SVN may reject it or become bitter towards it right off the
> bat and I want to avoid that.

I'm working on a PIII 600Mhz desktop at work with 512M RAM and same

The key to having speedy client side actions is to minimize the scope of
the repository that you are working with. The less files the working
copy needs to inspect the faster things are.

That may not be feasible depending on your development technologies and
work flows. For example one day I had to check in and apply some
patches to the linux kernel - I went for a coffee.


Wireless Group
McMaster University
14:23:41 up 34 days, 16 min, 4 users, load average: 0.22, 0.51, 0.45
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Aug 24 20:33:41 2005

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.