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

Re: [Issue 1429] 'svn checkout' unbelievably slow compared to cvs

From: <kfogel_at_collab.net>
Date: 2003-10-20 16:19:18 CEST

dwhedon@tigris.org writes:
> The profiles just attached correspond to r7437. In both cases I am
> checking out the source of gnuplot-3.8j.0 (2072307 bytes gzipped).
> For the ra_dav example apache is on the local machine. One
> interpretation is that we are spending a lot of time on checkout
> creating the vdelta. Since checkout is much like update for each
> file we currently calculate a vdelta against nothing and send the
> delta. I have a patch in the works that sends full text when we are
> comparing against nothing rather than calculating the delta. It
> looks like I will have some time this weekend, so maybe I'll even
> get it done :-)

Thanks, David! It's really nice to have more company on the profiling
work...

Just to make sure I understand what you're saying: you're talking
about a change whereby we would manually construct vdelta windows that
contain nothing but "fulltext" inserts, right? I.e., we'd still be
producing vdelta windows, but instead of doing so by diffing against
the empty string, we'd do it by building them directly.

I'm assuming this is your plan, because presumably, we can't just send
raw fulltext -- the consumer is still expecting vdelta data, though it
doesn't care how that data was produced, or whether any vdelta
compression is happening (we get compression when we calculate against
the empty string, but we won't get compression if we construct the
windows by hand).

Just sanity checking,
-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 20 16:56:47 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.