> > > 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
> swap.
>
> 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 2.6.8.1 linux kernel - I went for a coffee.
>
> Cheers,
> Chris
We do that regularly and that is a good workaround when we can do it,
but it can bite you when you update or commit only part of a tree - it
has bitten us a few times.
Robert
---------------------------------------------------------------------
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:47:17 2005