I've got some colleagues with a rather large Subversion repository
whose trunk includes over 10,000 files and over 500 Meg of actual
content for various reasons. What we're finding is that checking it
out it on a Windows client to a local hard drive takes perhaps 3
minutes. Downloading it to a mounted Windows (CIFS) share takes
roughly half an hour.
Linux clients operate just fine, checking out in less than 3 minutes
to a local or NFS mounted directory. Using TortoiseSVN or CygWin's
"svn" comman dmakes little difference, it's the downloading to a
Windows share, and the shares perform well for many other operations,
such as ordinary file transfers. And creating a working copy on a
Linux server, and then copying over that working copy, seems to work
quite well and takes only the 3 minutes of the Linux downloads . This
leaves me with questions:
* Is this poor CIFS performance normal for large repositories being
checked out? I assume it is because CIFS is so chatty, and that people
don't normally notice because they don't usually do such large
repositories and would hardly have noticed as the entertaining
hourglasses and text reporting of TortoiseSVN lets them know the
operation is occurring well.
* How bad are the risks of screwing up my checkouts if I use a
post-commit to keep a central working copy updated, and have people
simply copy that over instead of checking out the trunk directly? My
concerin is that the checkout process isn't really designed for that,
and may fail to do a checkout in a clean and atomic state, and the
checked out copy may therefore be corrupted by being in the midst of
an update operation.
Received on 2010-07-13 14:01:16 CEST