On May 30, 2011, at 22:58, Nico Kadel-Garcia wrote: > On Mon, May 30, 2011 at 2:43 PM, Ryan Schmidt wrote: >> >> On May 30, 2011, at 11:26, Nico Kadel-Garcia wrote: >> >>> There's a potential risk with the approach: CygWin uses UNIX >>> compatible end-of-line characters. TortoiseSVN, and other Windows >>> based clients, use Windows end-of-line. The result can be *CHAOS* if >>> you typically set source files, such as .html, .php, or .c, .sh, or >>> .pl files, to use "svn:eol-stile", or expect files to be automatically >>> set in Windows or UNIX style as you switch from programming from a >>> source repository in Windows, and one in CygWin. >> >> *Not* setting svn:eol-style to some value will lead to chaos, as you use >> different editors with different ideas of what a line ending is, and you >> start getting files with inconsistent line endings. *Setting* svn:eol-style >> to some value should prevent said chaos, by > > Then the editor, or practice of the developer, is fractured. In this > day of shared network based file systems and replication of developed > components via NFS, CIFS, SCP, and HTTP download, it is a dangerous > presumption that the EOL can be reset on a client system by client > system basis. CygWin is the best example of this: files checked out > and replicated with the CygWin based SVN will have one EOL for such > "clever" approaches, checked out with TortoiseSVN will have another. > The configured EOL approach to this which Subversion supports, as an > option, is hideously dangerous in such environments. > > There are a few cases where OS specific EOL is useful, but they're > rare. Markup languages have a standard EOL written in: so does C, > Perl, Ruby, Java, and all the other programming languages. It's only > really useful in poorly implemented configuration files which weren't > written with such a standard, and certain forms of stored text files, > and most editors and display tools can use those just fine. (Wordpad > versus Notepad, for example, works well for the Windows users.) > > I've actually seen this play out in C++ and Java and PHP and HTML in > the last.... 5 years. People checking out repositories on one OS to a > shared network directory, such as their Windows box with TortoiseSVN > for the superior interface, were alarmed to find the code mangled when > they did work with C, or replicated files and tried to import them > elsewhere *without* the same EOL settings. Chaos ensued repeatedly.
As far as I can tell, everything you wrote applies only to the case where you set svn:eol-style to native. Re-read my previous message. In it, I agree that setting svn:eol-style to native can cause certain problems, when your working copy crosses platform boundaries. However, NOT setting svn:eol-style to ANY value only invites the problem of getting files with inconsistent line endings committed to the repository, and THAT is something I would certainly want to avoid (and that can be achieved by setting svn:eol-style of text files to any value that pleases you: LF, CRLF, or native).
