CRLF issues on checkout (was Re: Gnucash 2.5/6 - jqplot)

[Geert Janssens]

Op 24-02-13 10:46, Christian Stimming schreef:
> Am Samstag, 23. Februar 2013, 18:23:13 schrieb Mike Alexander:
>>> I think the easiest way out here (as long as we're still using SVN)
>>> is to set  the per-file SVN property svn:eol-style to some fixed
>>> value (here: LF). This  ensures the file get one canonical set of eol
>>> markers.
>> Do you really want to use LF for eol-style for these file types?  I
>> would think that "native" would work better.  That's what I've been
>> using for years on various SVN projects and it seems to work well.  I
>> don't work on Windows much anymore, but I used to and often worked on
>> the same file on both systems.  "Native" is also what the stackoverflow
>> article you mention suggests.  If you specify this eol format then the
>> local file will be in the native format but the repository version will
>> always be with LF line endings.
> Yes, I do really want to set a deterministic eol-style instead of choosing the
> somewhat non-deterministic "native" style here. Think of it: We decide on one
> style, but with "native" you still say "well, depending on the OS you're
> looking at SVN, the files will end up this or that way." Not what I would call
> deterministic.
>
> I have one specific use case where "native" really fails: Some co-workers and
> me regularly work with a dual-boot machine that runs either Linux or Windows,
> but uses a SVN checkout on the same partition. With eol-style=native, the
> files in the identical working copy end up differently depending on the last
> OS I've used to work with the working copy. In that (admittantly pecurliar)
> case, one specific eol-style (LF or CRLF) works but eol-style=native does not
> work.
I had not mentioned this in my reply, but I have a similar setup. Not 
dual boot, but a primary linux machine and a Windows installation in a 
VM, sharing a common directory. This worked fine as long as I was 
working with svn (because we had explicitly set the EOL styles already). 
Once I switched to git I started running into several EOL issues again, 
which prompted me to write the .gitattributes file to match the svn config.

Recently I have moved away from the shared directory approach though. 
Now I use my linux repo as upstream repo for a dedicated repo for the 
Windows build. The disadvantage with this is that I have to check in 
anything I changed on the linux side before I can test in on the Windows 
side, but it's a minor inconvenience.
> On the other hand, there were times when eol-style=native was necessary:
> Earlier windows compilers would refuse to compile source code that did not
> have CRLF line endings. For Microsoft Visual Studio, this was no longer the
> case with at least MSVC 2005 (but I've encountered other cross-platform IDEs
> on windows that would still require CRLF line endings). If such a compiler is
> in the set of target platforms, then yes, using eol-style=native or CRLF is
> better.
This is also why some of the files in the win32 directory are marked 
explicitly for CRLF EOL style. The inno setup compiler is one of those 
tools that has issues with LF only EOL style. And for safety we also 
mark all windows native scripts as CRLF (.BAT and friends). I seem to 
remember them also behaving oddly when they used LF EOL.

Geert