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

Re: Corrupt repository on large commit (was Re: svn+ssh on Win32)

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2003-07-21 23:42:25 CEST

"Steve Williams" <stevewilliams@kromestudios.com> writes:

> > > Project #1 takes much longer (longer than Project #2) to perform the
> > > initial checkout.
> > > Again, it is my belief that it is the number of files, not the size of
> > > them, that causes the checkout to take so long.
> >
> > Yes, absolutely. A huge number of files will cause a huge REPORT
> > response from the server. If the server is *buffering* the entire
> > report before sending it to you, it will take a *really* long time
> > before you see a single file added to your working copy.
> >
> > Please please please, upgrade to 0.25, and turn off mod_deflate.
> As I said in my response, the client was hammering the local drive when the
> timeout error occurred. There was no network activity and no server drive
> activity. Surely this is not a sign that the server is buffering the
> report? I think the client was dealing with the report at the time the
> timeout error occurred.

Which is amazing to me... how can neon "timeout" on a response, when
it's actually *parsing* the response. I believe you when you said
that no compression was being used.

Your analysis is correct -- the client disk-thrash you hear is ra_dav
parsing the huge server response, and updating metadata in your
working copy about the results of the commit.

Steve, this is now filed as issue #1430. Can you add yourself to the
cc: list of that issue?

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 21 23:45:00 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.