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.
