Re: Could not read chunk size: connection was closed by server on Windows 7

Sorry for top posting, but see this FAQ:

http://subversion.apache.org/faq.html#secure-connection-truncated

It is the problem you are having. The error message just varies
between SSL and plain HTTP but the cause is the same. The client gets
busy doing something and the server thinks the client has gone away
and it kills the connection.

Are you using a Subversion 1.7 client? While I do not believe it
eliminates the problem, it does manage the working copy radically
different from SVN 1.6 and I would expect it to be less prone to this
problem.

On Thu, Feb 7, 2013 at 9:18 AM, Michael Zender
<michael.zender_at_mos-tangram.com> wrote:
> Hello everyone,
>
> a couple of days ago, I configured our apache webserver to serve our
> internal subversion repositories over plain old http. Before that, the
> repositories have only been accessible using https. Everything seemed to
> work pretty smoothly but after a couple of hours I had more and more
> complaints about problems that occurred while working (svn co, svn ls
> -v) with directories containing a large number of files (> 3000).
>
> The error message reported was something like the following:
> svn ls http://<servername>/<repourl>/<repopath> -v
> svn: PROPFIND of '/<repourl>/!svn/bc/<rev>/<repopath>': Could not read
> chunk size: connection was closed by server (http://<servername>)
>
> svn co http://<servername>/<repourl>/<repopath>
> svn: REPORT of '/<repourl>/!svn/vcc/default': Could not read chunk size:
> connection was closed by server (http://<servername>)
> An interesting fact about the checkout is, that the working copy has
> been created and so far I've had no problem with it.
>
> I started investigating and was able to reproduce the problem first in
> the live environment before replicating it on a completely different
> server. The specs are:
> OS: Debian GNU/Linux 6.0.6 (squeeze)
> Webserver: Apache/2.2.16
> Subversion: svn, version 1.6.12 (r955767)
>
> I created a test repository with the following script
> svnadmin create project_Test
> chown www-data:www-data project_Test -R
> svn co file:///var/lib/subversion/project_Test wc_project_Test
> cd wc_project_Test
> mkdir src
> for i in {1..1000}
> do
> head -c 10K < /dev/urandom > src/testfile$i.dat
> done
> svn add src
> svn ci -m "test commit"
>
> The script creates a new repository "project_Test" containing a src
> directory with 1000 10kB files with random content.
>
> And made it available in via apache using the following VirtualHost
> configuration:
>
> <VirtualHost *:80>
> ServerName svntest
>
> <Location /svn>
> DAV svn
> SVNParentPath /var/lib/subversion/
> SVNListParentPath On
> </Location>
> </VirtualHost>
>
> With this setup I was able to reproduce the checkout problem. I
> increased the number of files in the directory to up to 4500 but as of
> now, I've not been able to reproduce the svn ls -v problem.
>
> I did a lot of analysis and my conclusion is, that the problems only
> occur on Windows 7 using any client software we have in use (Eclipse
> integrated client, TortoiseSVN, sv command line client). On WindowsXP
> as well as on Linux, there's no problem at all working with the
> repository using http communication. When I execute the svn co operation
> on a debian system installed on a VirtualBox VM hosted on my Windows 7
> I have the same problem as directly on the Windows 7 client.
>
> I know that there are a lot of emails on this list describing the same
> error message and I spent quite some time to scan through them and to
> follow the links but so far none of them contained a solution for my
> particular problem.
>
> I'll also gladly provide any further information that you find useful to
> further analyze the problem.
>
> Thank you very much in advance for your help!
>
> Michael

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/