|
Boost : |
From: David A. Greene (greened_at_[hidden])
Date: 2007-07-31 20:49:25
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.
-Dave
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk