[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: Ryan Schmidt <subversion-2011a_at_ryandesign.com>
Date: Sun, 13 Nov 2011 18:25:16 -0600

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.
Received on 2011-11-14 01:26:29 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.