2007/8/1, David A. Greene <greened@obbligato.org>:
On Tuesday 31 July 2007 18:12, Douglas Gregor wrote:
On Jul 31, 2007, at 7:08 PM, Douglas Gregor wrote:
Here's my theory: you are checking out a large repository to a networked filesystem, say, NFS. The Subversion client downloads a ton of data and writes it to many, many small files. The networked filesystem slows to a crawl under the load (creating many small files is a particularly bad case for many networked file systems), and essentially the Subversion client can't keep up with the server that is feeding its data. After a while, the Subversion server gets bored of waiting for the client and closes the connection.
I absolutely agree with your diagnosis.
The problem with Subversion is not the timeouts per se. If that's all that happened, it would be an annoyance.
The problem with Subversion is that these timeouts can sometimes cause working directory corruption. That is absolutely, positively unacceptable for anyone doing critical work. Note that I'm not talking about errors from the network filesystem itself (broken connections causing errors on file I/O, etc.). I'm talking about http protocol timeouts. Subversion should be resilient enough to exit gracefully under such circumstances and it doesn't always do that.
I have had some experience of svn HTTP timeouts resulting from an overloaded server (nothing to do with Boost). In this case, it looked as if the working copy had become corrupt. However, after asking on the svn mailing list, it turned out that the "corruption" could be fixed with a simple command. The problem is that the client gives unhelpful error messages, and the commands to recover are unintuitive - both problems that ought to be fixable. Specifically, it seems that if an "svn commit" fails due to an HTTP timeout after the commit has happened in the repository, then you need to do an "svn update" to get the working copy back in sync, yet the error (unhelpfully) suggests "svn cleanup". Or something like that. Of course there may be other scenarios in which the corruption is real [e.g. your timeout during update rather than commit], but based on what I've seen I would never abandon an apparently-corrupt working copy without first posting a "here's what I did and here are the errors I got" question to subversion_users. Concerning subversion performance in general, I have found that the Apache authentication method chosen has a greater effect than anything else. Regards, Phil.