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.
