Re: [boost] development branch(es)

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.

Regards,

Phil.