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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
