On Thu, Nov 10, 2011 at 12:48 PM, Ryan Schmidt <subversion-20...@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.)