From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2007-08-01 11:18:41
> 2007/8/1, David A. Greene <greened_at_[hidden]>:
>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk