On Wed, Jan 25, 2012 at 7:26 AM, Ryan Schmidt
<subversion-20...@ryandesign.com> wrote:
> 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.
>
Nice summary, thanks.
> * 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.
>
No, this has not been addressed yet. There is a feature request in the
issue tracker:
http://subversion.tigris.org/issues/show_bug.cgi?id=4065 (server
should enforce LF normalization for svn:eol-style=native files)
but I don't think anyone is actively working on it.
BTW, if anything should be done to the documentation, maybe simply a
warning that svn:eol-style=native should not be used when a working
copy is shared between different platforms (because of the changing
definition of what "native" means).
--
Johan
