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.
