"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