I apologize in advance if the below reply is snarky, but I'm a little tired of this particular topic; it has been talked to death already long ago.
On Jan 24, 2012, at 19:24, Nico Kadel-Garcia wrote: > The big booby trap I notice with all Windows/Subversion use is the > understandable desire to use "native" end-of-line characters to swap text > files gracefully between Linux, Windows, and MacOS. Don't do that: it can > bite you *VERY* hard if you access the same network filesystem, such as a > CIFS share, from each of those operating systems or with CygWin on Windows. Nico, I know you have a strong opinion about the svn:eol-style property, specifically that it should never be used, and you love voicing this opinion in as many threads on this mailing list as possible, regardless of whether it is relevant to the thread or not. I'll respond yet again, in a different form that is perhaps more effective in explaining my views: There are several kinds of files you might have in your repository: 1. Binary files, such as images, sounds, videos, compiled programs, compressed archives, spreadsheets, presentations, some word processing documents, etc. Setting svn:eol-style to any value on these files would likely corrupt them, so svn:eol-style should not be set on these kinds of files. 2. Text files where you want some lines to have LF line endings and other lines to have CRLF line endings. I hope there is agreement that nobody ever wants these kinds of files, yet this is exactly the kind of file you will get if you do not set svn:eol-style, and you have several different people editing the files, on different platforms, using different editors. That was my actual experience at the last company I worked for. The specific problem editor in our case was UltraEdit on Windows, which happened to be the editor my company had paid for, so it was the one most of our developers were using. Unless you set four separate settings in its options window to four specific non-default values (which you had to wade through a hundred other options to find), it had very strange ideas about how line endings should be handled. (It preserved the existing line ending style for lines you did not edit, but used CRLF line endings for any lines you did edit.) Therefore, I recommend you always set the svn:eol-style property of text files to some value. What value? Read on. 3. Text files where you want line endings to always be LF regardless of platform. In this case, set svn:eol-style to LF. The Subversion client transforms the file's line endings to LF before commit, and when you check out, gives you a file with LF line endings. If you or your broken editor somehow transform some of the file's lines to CRLF line ending, the Subversion client* will prevent you from committing that broken text file back to the repository until you fix the broken line endings so that they are consistent. Hooray. Note that there is no problem if you or your editor convert the *entire* file to a different line ending style before committing; Subversion will seamlessly convert it back to the line ending style indicated in the svn:eol-style property. 4. Text files where you want line endings to always be CRLF regardless of platform. In this case, set svn:eol-style to CRLF. In the same spirit as (3) above, the Subversion client* will ensure the file in the repository has only CRLF line endings. 5. Text files where you want line endings to be CRLF if checked out with a native Windows client, and LF otherwise. In this case, set svn:eol-style to native. Subversion will store the file in the repository with LF line endings. When checking out on native Windows, it will convert the line endings from LF to CRLF, and on commit, will convert back to LF. On non-Windows systems (including cygwin, I believe), the files will be checked out and committed in their unconverted state using LF line endings. Yes, you will run into problems if you share a working copy between native Windows and non-Windows (including cygwin IIRC) environments. Rather than state that svn:eol-style should therefore never be used, or should never be set to native, you should instead stop sharing working copies. If you cannot give that up, then yes, in your specific unusual case, setting svn:eol-style to native might not be a good idea. Do not however condemn the use of svn:eol-style native for everyone, nor the use of svn:eol-style in general. I manage a repository of web site code. It contains HTML web pages, CSS stylesheets, JavaScript code, Markdown-formatted documentation. On my Mac I prefer these files to have LF line endings, because if I want to use UNIX command line tools on these files, they work best with LF line endings, and GUI editors on OS X default to LF line endings too. I assume Windows users would prefer them to have CRLF line endings, because that's what Notepad and probably other Windows editors work best with. Therefore these files all have svn:eol-style set to native. Anybody checking out the repository will get text files with a line ending style appropriate to the environment they checked out to, and everybody is happy. * The caveat is that it is the Subversion *client* that performs the line ending translation and verification; last I checked, the server does not verify that the client has submitted data that conforms to the file's stated svn:eol-style. It is therefore possible for a broken Subversion client to commit the wrong line endings. An example of a broken Subversion client is git-svn. You can work around this by writing a pre-commit hook. IIRC last time this was brought up somebody said the server should be fixed to detect this itself; I don't know if this has happened.
