John Thile wrote:
> The main problem I'm seeing right now is that checkouts take an
> extremely long time and always fail partway through, requiring a
> process like this: checkout, fail; update, fail; update, fail; update,
> complete. After that, one has the repository and further updates do
> not fail. However, even then an update which winds up pulling down
> only, say, 200 KB of changed data will take, on average, thirty
> minutes. The error on new checkouts is below:
>
> Error: REPORT request failed on '/<path edited>/!svn/vcc/default'
> Error: REPORT of '/<path edited>/!svn/vcc/default': 200 OK (http://foo
> <http://foo>)
I had a similar problem. I discovered that SVN basically timeouts on itself if
a fail takes longer to download than the timeout time. To fix this, you have to
tweak the configuration file named "servers", which is next to the more famous
"config" (on Windows, under %HOME%\Application Data\Subversion). My own looks
like this (slightly edited):
-------------------------------------------
[groups]
universe = *
[universe]
http-timeout = 120 # seconds
-------------------------------------------
Notice that the problem can happen even during an "update". It is sufficient
that a delta transmitted for the changes of a file is longer than the default
timeout.
It is absolutely questionable whether the "HTTP timeout" should refer to the
total time a single file (or delta) takes to be transferred, or the time since
the last TCP/HTTP packet arrived. I raised this concern before, but got answers
like "this is by design", which are totally unsatisfactory for me. They mean
that SVN over HTTP is broken by default with files large enough or
connections slow enough.
--
Giovanni Bajo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Oct 7 20:41:19 2006