On Thu, Nov 10, 2011 at 12:48 PM, Ryan Schmidt
<subversion-2011a_at_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.)
Received on 2011-11-13 08:47:29 CET