> I have a fairly large repository (~75 GB) containing mostly binary
> files (photos).
> When I try to do a checkout, it fails after checking out about 7.5 GB.
> On the client, this error is shown:
> svn: REPORT of '/svn/photo/!svn/vcc/default': Could not read response
> body: Secure connection truncated (https://svn)
> svn co https://svn/svn/photo tdn-photos 1635,48s user 289,84s system
> 8% cpu 6:03:45,40 total
> On the server, this error is written in the log:
> ==> /data/www/virtual/svn/log/error.log <==
> [Fri Aug 12 00:42:09 2011] [error] [client 10.0.0.4] Provider
> encountered an error while streaming a REPORT response. [500, #0]
> [Fri Aug 12 00:42:09 2011] [error] [client 10.0.0.4] A failure
> occurred while driving the update report editor [500, #103]
> [Fri Aug 12 00:42:09 2011] [error] [client 10.0.0.4] Error writing
> base64 data: Software caused connection abort [500, #103]
> ==> /data/www/virtual/svn/log/access.log <==
> 10.0.0.4 - tdn [11/Aug/2011:18:38:35 +0200] "REPORT
> /svn/photo/!svn/vcc/default HTTP/1.1" 200 4094599482 "-" "SVN/1.6.12
> (r955767) neon/0.29.5"
> I have tried turning off SSL and thus using regular HTTP instead of HTTPS.
> This did not fix the problem. I receive the same error.
> I hope you can help me fix this problem.
I've run into similar problems where the total commit size was large and the network speed to the server was slow (or blocked up). If the network link is not cleared fast enough this seems to cause things to timeout in the webdav layer. In our case it was actually write speed to NFS drives at the client end on our build farm that was slowing the whole process and backing up the network connection.
The simplest workaround we found was to restart the update as the client detects the failure and appears to clean up the working copy so that a restart is possible.
The following links describe what we ran into but we never really got a better solution rather than the above one I'm afraid:
Hope this helps.
Received on 2011-08-16 09:23:21 CEST