On Thu, Nov 10, 2011 at 7:21 AM, David Weintraub <qazw...@gmail.com> wrote: > > > On Thursday, November 10, 2011, markw <ma...@hmgcc.gsi.gov.uk> wrote: >> Hi All >> >> I am trying to compile a best practice guide for my organisation's >> Subversion users. I am now thinking about the issue of checking out to a >> network drive. It looks like over the years this has generated a number of >> issues for the community. So I would be very interest to hear if this has >> caused anyone any problems? - > > The big issue is storing a repository on a network drive and having everyone > access it via the file:// protocol. That is a bad idea . > > On many Unix systems, your home directory is a network drive, and on Windows > systems, the My Directory is a share. So, doing a checking out on a network > is not that rare and may be the only way you can do a check out.
CIFS checkouts used to be *horrible* for large working copies of many thousands of files in one directory. This has allegedly gotten vastly better with recent releases. (I did significant testing with CIFS 2.x to see if that helped, it didn't). I used to have to keep a checked out working copy that people could replicate from to gain a 100-fold speed improvement over normal checkouts on CIFS. On NFS, it it was no faster to check out than to replicate. There are risks of people all working inside the same working copy: They can be editing a file when you're in the midst of committing your changes, a good reason to maintain *distinct* branches. If you need. The ideal behavior of commits being "atomic" becomes imperiled if someone else can edit a file while you're committing it. (This could be worse: I had huge issues with an impolite person who would "view" files with "vi" while I edited and tried to commit with Emacs, and when he quit it would *revert my changes* in the working copy. "vi" is for editing, "less" is for viewing!) Windows versus UNIX style end-of-line also becomes important. The "svn:eol" style for files in a shared repository will behave differently on Windows boxes accessing a CIFS share from a UNIX or Linux box via Samba than the UNIX or Linux box will provide with local or NFS access to exactly the same working copy if that is set. Also, naming conventions become important, becuase CIFS does not support multiple files that only differ in capitalization for the same name, but a UNIX or Linux access to the same working copy will handle it merrily if the access is direct or NFS based. I spent a *lot* of time explaining this to verious people trying to use multiple platform shared access, and running headlong into the problems they thought they'd "cleverly" worked around. It became an adventure to explain why svn:eol should be deprecated, preferably with a claw hammer.