I had the same issue and since it is a big checkout but don't have access to extend the server timeout, solved it by issuing:
$ svn cleanup
$ svn up
Each time I got this error (until the checkout was complete).
This is apache server problem related to timeout (SVN client dont work as it's needed with huge number of big files). Put here on httpd.conf and do a restart of httpd, and problem will be resolved, without future needs to do cleanup and update:
Timeout 12000
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
this is my solution:
1 - use cleanup or sudo cleanup
svn cleanup
2- use update or sudo update
svn update
Try setting http-timeout client parameter to a large value as explained here: https://mail-archives.apache.org/mod_mbox/subversion-users/201410.mbox/%3CF98FEACF1869AF4497A996B6F32D22600A91CA@NHL-SVEX01.WSD.L-3Com.com%3E
~/.subversion/servers:
[global]
http-timeout = 6000
http://www.hostingezpublish.com/FAQ/Solving-checkout-problems-with-svn-repositories
SVN 1.8 includes a new HTTP client library (Serf).
which I think is responsible for this. I had installed TortoiseSVN-1.8.6.25419-x64-svn-1.8.8.msi and performing svn merge gave same error. Initially I though it is problem with svn server timeouts but same merge operation worked with 1.6. So I guess problem is with SVN version 1.8 and above. Please revert your svn client version to 1.7 or 1.6 and try!
Reason of this error is that opening one of internal SVN files on server fails. This is server issue, but not bug.
If your SVN server software is apache WebDAV extension on Linux:
You need to go to location on server, where apache stores the repository database. Use sudo chown -R www-data:www-data folder_name to change the folder owner. Problem with commits from clients will disappear.
That's all i know about this error.
This can happen during big checkouts or big merges when you serve code via svn webdav. Usually extending server timeout will help.
today I have faced the same issue by using SVN 1.9.9 and gathering some 'diff' data by SVN command line from an apache SVN server. Well the suggestion from 'Kompjuteras' to set the apache configuration parameters as follows [== to increase especially the timeout]:
"Timeout 12000
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15"
has solved the problem (instead of Timeout 12000 I have set it just to 3600 [== 1h]). Furthermore there was a question above from 'Ethan Field' about the meaning of the parameters. They are explained very well here: http://httpd.apache.org/docs/2.4/mod/directives.html
Well I think the issue described here is caused by a too short 'Timeout' configured at the SVN apache server. (Default is just 60 == 1MIN since version 2.4!!!!!)
Good luck & Thanks a lot!
Possibly a bit late but if you're frantically Googling this problem and your Subversion server has recently updated to Debian Buster you may want to try your luck with this option in your Apache's Subversion repository vhost:
SVNAllowBulkUpdates prefer
Put that after the SVNParentPath directive, do sudo service apache2 reload, and try a checkout again.
Source: https://audeuro.com/node/44
What this setting does (quoting from the subversion manual):
Toggles support for all-inclusive responses to update-style REPORT requests. Subversion clients use REPORT requests to get information about directory tree checkouts and updates from mod_dav_svn. They can ask the server to send that information in one of two ways: with the entirety of the tree's information in one massive response, or with a skelta (a skeletal representation of a tree delta) which contains just enough information for the client to know what additional data to request from the server. When this directive is included with a value of Off, mod_dav_svn will only ever respond to these REPORT requests with skelta responses, regardless of the type of responses requested by the client.
Most folks won't need to use this directive at all. It primarily exists for administrators who wish—for security or auditing reasons—to force Subversion clients to fetch individually all the files and directories needed for updates and checkouts, thus leaving an audit trail of GET and PROPFIND requests in Apache's logs. The default value of this directive is On.
This sounds a bit out of date. I suspect that if you have a fairly large repository the size of an all-inclusive report may simply be too large for transit, so the "most folks won't need to use this directive at all" comment no longer applies.
In my situation this was being caused by some "transparent" infrastructure between the SVN server and my workstation. I suspect it was a proxy (websense / mcafee / forcepoint).
Most of the commits were fine, but it was failing to stream the content of one particularly large commit, presumably the content was too large and was causing the proxy to crash / drop the connection.
I was able to resolve by bypassing this infrastructure. In my case, i was able to set an alternative proxy in my .git/config which bypasses the problematic infra.
You did not write what version is your SVN server. Probably your issue will be solved when you downgrade your client to 1.7 - you will have to delete the local repository and synchronize it again because of incompatibility between versions 1.8 and 1.7.
