[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Network Share Checkouts

From: Nico Kadel-Garcia <nkadel_at_gmail.com>
Date: Thu, 10 Nov 2011 08:27:52 -0500

On Thu, Nov 10, 2011 at 7:21 AM, David Weintraub <qazwart_at_gmail.com> wrote:
> On Thursday, November 10, 2011, markw <markw_at_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.
Received on 2011-11-10 14:28:25 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.