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

Re: Speedup of svn on NFS?

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: Thu, 26 Jun 2008 00:59:21 +0200

On Thu, Jun 26, 2008 at 12:35 AM, Alfred Perlstein <bright_at_mu.org> wrote:
> * Erik Huelsmann <ehuels_at_gmail.com> [080625 15:20] wrote:
>> On Mon, Jun 23, 2008 at 11:05 PM, Alfred Perlstein <bright_at_mu.org> wrote:
>> > Hey guys, I've been doing some analysis of SCM tools for my company,
>> > one thing I've been noticing is that they do many filesystem meta-data
>> > operations that _appear_ to be unncessary.
>> There used to be many of them, not only on the meta-data level, but
>> even copying entire files. It has to do with the design of the working
>> copy library and the layering in it. Did you analyse the 1.5 version?
>> At least 1.5 should be a bit better than earlier versions.
>> > For instance, when doing a "svn checkout" I'll see ".svn/tmp/entries"
>> > created many times, and then renamed over ".svn/entries".
>> >
>> > Is there any way to reduce these items when you _know_ you're going
>> > to be working in isolation?
>> > Could this be made any faster by just updating the files in place?
>> No, because none of it has to do with 'working in isolation': this has
>> to do with 'working copy correctness'.
> What if a user could use the flag because he _knew_ that he
> wasn't going to do something bad?
> For instance, I'd happily take a 50%+ speedup of my "svn checkout"
> on the condition that if I hit ^C that it would be useless and
> had to be thrown away (rm -rf).
> Call it "svn fastcheckout" or something.
>> > It would really add up.
>> Yup. It's a known problem; we hope to address it in a new design of
>> the working copy.
> I don't think that a redesign is needed, just optionally reducing
> some of the consistencies, particularly when it's not needed.
> For instance, if you were untarring something and hit "^C" does
> it really matter to you if you need to rm -rf and start over?
> No, because untarring the file in some way as to take advantage
> of the already extracted files is not worth the time to figure
> out.

Except that for the current implementation 'svn update' and 'svn
checkout' can actually share the same code, meaning that you get a
well-tested, stable and reliable VC. A very important property, I'd
say. We'd like to keep complexity of the system within bounds, meaning
we'd rather not add special cases. To make checkout/update faster in
the general case (much more worth our effort, I'd say, than a special
case), we do need the rewrite.

Thanks for your feedback!



To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-06-26 00:59:47 CEST

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.