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

Re: Errors while checking out large directory

From: Andy Levy <andy.levy_at_gmail.com>
Date: Mon, 18 Jan 2010 09:27:32 -0500

On Mon, Jan 18, 2010 at 08:55, Mark Phippard <markphip_at_gmail.com> wrote:
> On Mon, Jan 18, 2010 at 8:44 AM, Andy Levy <andy.levy_at_gmail.com> wrote:
>>> You should be able to just edit the %AppData%\Subversion\servers file
>>> on the client to tell it to use Serf over Neon (assuming your binaries
>>> support it).
>>>
>>> [global]
>>> http-library = serf
>>>
>>> If Anthill uses SVNKit then I am not sure what you can do other than
>>> increase the timeout on the server.
>>
>> I'll experiment some with the client config this morning, thanks.
>>
>> I'm not presently capturing User-Agent in my httpd logs - if I was,
>> would that help me identify whether a client is using Serf or Neon?
>
> Neon is the default so it is pretty unlikely someone would be using
> Serf.  I do not think the User-Agent identifies which library is used.
>  It does however, tell you if SVNKit is being used.
>
> The request pattern in the logs between Serf and Neon is very
> different and that would be the main giveaway.  An update with Neon is
> mostly a single large REPORT request.  With Serf it is a small REPORT
> request followed by a GET for each resource you need to update.

Looks like Anthill can't use serf, my logs show the same pattern
between yesterday & today. I know that the client config is being
picked up from the right place because use-commit-times is being
honored.

Here's what I'm seeing:

172.30.5.40 - - [17/Jan/2010:20:56:02 -0500] "PROPFIND PATH HTTP/1.1" 207 736
172.30.5.40 - - [17/Jan/2010:20:56:02 -0500] "REPORT
/Repos/Code/!svn/vcc/default HTTP/1.1" 200 883378845

883MB response being streamed back to the client, I guess the default
5 minute timeout isn't quite enough sometimes.

The way I have things configured, Anthill is checking out a copy of
the project while Tomcat is finishing the deployment of the previous
build into its temp/working directory. Maybe these overlapped
I/O-intensive tasks are slowing each other down? Often the first build
succeeds, and subsequent ones fail. I'll have to try doing them
independently later today.
Received on 2010-01-18 15:28:06 CET

This is an archived mail posted to the Subversion Users mailing list.