Network Share Checkouts

[markw <ma...@hmgcc.gsi.gov.uk>]

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? Anyone know of any problems? What is the 
general consensus around this?

Thanks
Mark

The information contained in this message (and any attachments) may
be confidential and is intended for the sole use of the named addressee.
Access, copying, alteration or re-use of the e-mail by anyone other
than the intended recipient is unauthorised. If you are not the intended
recipient please advise the sender immediately by returning the e-mail
and deleting it from your system.

This information may be exempt from disclosure under Freedom Of Information 
Act 2000 and may be subject to exemption under other UK information 
legislation. Refer disclosure requests to the Information Officer.


The original of this email was scanned for viruses by the Government Secure Intranet virus scanning service supplied by Cable&Wireless Worldwide in partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On leaving the GSi this email was certified virus free.
Communications via the GSi may be automatically logged, monitored and/or recorded for legal purposes.

Re: Network Share Checkouts

[Les Mikesell <le...@gmail.com>]

On Thu, Nov 10, 2011 at 8:13 AM, Nico Kadel-Garcia <nk...@gmail.com> wrote:
>
 On Thu, Nov 10, 2011 at 8:46 AM, Les Mikesell <le...@gmail.com> wrote:
>> On Thu, Nov 10, 2011 at 7:27 AM, Nico Kadel-Garcia <nk...@gmail.com> wrote:
>>>
>>> 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.
>>
>> Ummm, no.  Using other ways of move files across systems that need
>> eol-munging shouldn't have been considered in the first place. There's
>> a long, long history.
>
> Les, "moving" wasn't the problem. Inheritance was. People who'd not
> paid attention to their CVS->Subversion migrations, or inconsistently
> laid defaults and inherited svn:eol settings of any kind were alarmed
> when their working copy accessed in Linux for compilation, but managed
> with TortoiseSVN for the superior management GUI, proceeded to have
> real end-of-line management problems. And this is *precisely* the sort
> of issue that can occur with shared network drives.
>
> It's especially an issue with files get "added" or "imkported" and a
> different svn:eol policy gets set, and then you have to *change* it.
> on the fly. This kind of clean-up whackiness is why constintly setting
> the EOL as a matter of document type, not local operating system, is
> so useful.

I'm not sure I see a point here.  There are lots of things that you
have to get right or things won't work, and this is one of them.  We
can't change history and pretend that text is the same on every system
even though the difference looks like a mistake in retrospect.

---
   Les Mikesell
     lesmikesell@gmail.com

Re: Network Share Checkouts

[Nico Kadel-Garcia <nk...@gmail.com>]

On Thu, Nov 10, 2011 at 8:46 AM, Les Mikesell <le...@gmail.com> wrote:
> On Thu, Nov 10, 2011 at 7:27 AM, Nico Kadel-Garcia <nk...@gmail.com> wrote:
>>
>> 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.
>
> Ummm, no.  Using other ways of move files across systems that need
> eol-munging shouldn't have been considered in the first place. There's
> a long, long history.

Les, "moving" wasn't the problem. Inheritance was. People who'd not
paid attention to their CVS->Subversion migrations, or inconsistently
laid defaults and inherited svn:eol settings of any kind were alarmed
when their working copy accessed in Linux for compilation, but managed
with TortoiseSVN for the superior management GUI, proceeded to have
real end-of-line management problems. And this is *precisely* the sort
of issue that can occur with shared network drives.

It's especially an issue with files get "added" or "imkported" and a
different svn:eol policy gets set, and then you have to *change* it.
on the fly. This kind of clean-up whackiness is why constintly setting
the EOL as a matter of document type, not local operating system, is
so useful.

Re: Network Share Checkouts

[Les Mikesell <le...@gmail.com>]

On Thu, Nov 10, 2011 at 7:27 AM, Nico Kadel-Garcia <nk...@gmail.com> wrote:
>
> 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.

Ummm, no.  Using other ways of move files across systems that need
eol-munging shouldn't have been considered in the first place. There's
a long, long history.

-- 
   Les Mikesell
     lesmikesell@gmail.com

Re: Network Share Checkouts

[Ryan Schmidt <su...@ryandesign.com>]

On Nov 13, 2011, at 01:46, Nico Kadel-Garcia wrote:

> On Thu, Nov 10, 2011 at 12:48 PM, Ryan Schmidt wrote:
>> 
>> On Nov 10, 2011, at 07:27, Nico Kadel-Garcia wrote:
>> 
>>> 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.
>> 
>> 
>>> 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.
>> 
>> Every time you bring this up I have to point out that what you're talking about applies only when a file's svn:eol-style property is set to "native". It does not apply when svn:eol-style is set to another value, such as "LF" or "CRLF", nor does it apply if svn:eol-style is not set.
> 
> No, it happens *every time* yous set it to "native" and wind up
> editing code in one OS and running it in another. [snip]

...right, that's what I said. There is a potential for unexpected problems of the kind you describe when you set svn:eol-style to native. But there is no problem when you set svn:eol-style to LF or CRLF. I was taking exception to your overgeneralization that "svn:eol [sic] should be deprecated"; it should not, because it works fine and serves a useful function.

Re: Network Share Checkouts

[Johan Corveleyn <jc...@gmail.com>]

On Sun, Nov 13, 2011 at 8:46 AM, Nico Kadel-Garcia <nk...@gmail.com> wrote:
[...]
> No, it happens *every time* yous set it to "native" and wind up
> editing code in one OS and running it in another. It's particularly a
> problem when people use TortoiseSVN to a CIFS accessible for code or
> documents that get run on a distinct OS. For scripting languages it's
> particularly adventuresome. The replication and addition of a file
> other than with 'svn copy' requires manual or semi-automated setting
> of "svn:eol", or the new files will have a distinct configuraiton.
> Then when you *change* them to match, diffs get complicated.
>
> The whole thing is better dealt with by following git's model. "Don't
> touch the bytes once submitted, what comes out is byte-for-byte what
> you put in". I can see uses for 'Id' and 'URL', but this end-of-line
> confusion is just that far too often: confusion.

As I said already in another thread: we have no problem at all with
the eol-style=native feature. We are very happy with it. Of course, we
don't use working copies shared accross different OS's. As long as you
understand what you're going to get with this feature, I see no
problem with it.

Besides, it's easy to block use of this feature, just disallow setting
the eol-style property in your pre-commit hook. Then you'll get the
same byte-for-byte behavior as what you're advocating.

-- 
Johan

Re: Network Share Checkouts

[Nico Kadel-Garcia <nk...@gmail.com>]

On Thu, Nov 10, 2011 at 12:48 PM, Ryan Schmidt
<su...@ryandesign.com> wrote:
>
> On Nov 10, 2011, at 07:27, Nico Kadel-Garcia wrote:
>
>> 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.
>
>
>> 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.
>
> Every time you bring this up I have to point out that what you're talking about applies only when a file's svn:eol-style property is set to "native". It does not apply when svn:eol-style is set to another value, such as "LF" or "CRLF", nor does it apply if svn:eol-style is not set.

No, it happens *every time* yous set it to "native" and wind up
editing code in one OS and running it in another. It's particularly a
problem when people use TortoiseSVN to a CIFS accessible for code or
documents that get run on a distinct OS. For scripting languages it's
particularly adventuresome. The replication and addition of a file
other than with 'svn copy' requires manual or semi-automated setting
of "svn:eol", or the new files will have a distinct configuraiton.
Then when you *change* them to match, diffs get complicated.

The whole thing is better dealt with by following git's model. "Don't
touch the bytes once submitted, what comes out is byte-for-byte what
you put in". I can see uses for 'Id' and 'URL', but this end-of-line
confusion is just that far too often: confusion.


>> 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.
>
> Case conflicts are an issue you'll want to avoid if you have Mac users too, since the default Mac filesystem is case-insensitive too, just like on Windows.

I avoid commenting on the Mac experience, because I don't have one.
(Wouldn't mind one, but I tend to install Linux on them.)

Re: Network Share Checkouts

[Ryan Schmidt <su...@ryandesign.com>]

On Nov 10, 2011, at 07:27, Nico Kadel-Garcia wrote:

> 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.


> 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.

Every time you bring this up I have to point out that what you're talking about applies only when a file's svn:eol-style property is set to "native". It does not apply when svn:eol-style is set to another value, such as "LF" or "CRLF", nor does it apply if svn:eol-style is not set.

I would strongly advise users to set svn:eol-style of their text files to LF or CRLF as appropriate, to avoid the problem of getting inconsistent line endings in the file due to using different editors with different settings or on different platforms. Using svn:eol-style native is also fine, so long as you understand that working copies should not be shared among operating systems with different line ending styles.


> 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.

Case conflicts are an issue you'll want to avoid if you have Mac users too, since the default Mac filesystem is case-insensitive too, just like on Windows.

Re: Network Share Checkouts

[Nico Kadel-Garcia <nk...@gmail.com>]

On Thu, Nov 10, 2011 at 7:21 AM, David Weintraub <qa...@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.

Re: Network Share Checkouts

[David Weintraub <qa...@gmail.com>]

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.

--
David Weintraub

-- 
David Weintraub
qazwart@gmail.com

Re: Network Share Checkouts

[Ryan Schmidt <su...@ryandesign.com>]

On Nov 10, 2011, at 03:08, markw wrote:

> 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? Anyone know of any problems? What is the general consensus around this?

My experience is that you might run into some performance problems that may or may not be significant, and you may run into permissions issues that may completely prevent working copies from being usable for you.