From: Douglas Gregor (doug.gregor_at_[hidden])
Date: 2007-07-31 19:08:06
On Jul 31, 2007, at 3:40 PM, David A. Greene wrote:
>> Then, it suggests either some particular flakiness in your network
>> environment, or your svn client is somehow broken.
>
> If "flakiness" means "latency," then that may very well be the
> case. But
> network latency is not an issue of "flake." It's a reality of
> life. Things
> should not break due to latency. Certainly working directories should
> not get corrupted! That is a showstopper for me and is why I
> refuse to
> put any of my personal projects into Subversion.
Okay, I looked into this.
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.
Why does turning off http compression help? Probably because turning
off compression makes for much more Subversion server->client
traffic, and gives the networked file system time to catch up when it
is writing files. Since compression ratios for source code can be
very high, and networked file systems generally don't compress data
when transmitting files, there would be a very large imbalance
between the server->client transfers and the client->file system
transfers.
What's the solution? If I'm correct, checking out to a local file
system should solve the problem immediately (and would be much, much
faster anyway). Additionally, we can (and have) bump up the timeout
values on the server side to try to keep it from severing connections
too early.
Anyway, try out the Boost Subversion repository to see if it works
for you. If not, we'll see what we can do.
- Doug