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

Re: Slowness of svn and http

From: Greg Stein <gstein_at_lyra.org>
Date: 2003-07-17 20:13:42 CEST

On Thu, Jul 17, 2003 at 10:49:01AM -0700, Jack Repenning wrote:
> At 12:28 PM -0500 7/17/03, Kirby C. Bohling wrote:
> >As nearly as I can tell, that's roughly what a check out of HEAD is.
> >You get the files from apache, you uncompress them once, you write them
> >to disk twice. That'd give you a rough idea of what the overhead of
> >running subversion is. Did I get that correct?
> I'm not sure what this experiment tells us. The net result of this
> process is only files on your local disk; it does not connect you to
> the VC system. If that's all you need, then by all means, just
> download and unpack the tarball once!
> On the other hand, if you're actually looking for VC (so you can get
> changes more efficiently, or so you can commit changes back in, or
> all the other stuff that VC provides), then it's hard to understand
> the spread between this experiment and actual VC. This experiment
> doesn't include creating the various state stuff in .svn/ (you've
> covered the base text copy, but not the rest). This experiment also
> doesn't cover any of the server-side work necessary to accomplish
> your request (selecting the particular versions you want).

Right, but the experiment tells us about the resulting costs of those
overheads. If we spend another 30 minutes over {download, unzip, untar,
untar}, then it says we spend 30 minutes creating .svn and with server-side
work, or with wire overhead, or whatever.

In an ideal world, a checkout would be just as fast as a download. So the
question is: how close are we?


Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 17 20:07:51 2003

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.