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