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

[Geert Janssens]

Op 24-02-13 00:23, Mike Alexander schreef:
> --On February 23, 2013 5:07:47 PM +0100 Christian Stimming 
> <christian at cstimming.de> wrote:
>
>> 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.
>>
>> However, setting this property requires a client-side action: Either
>> the file  ~/.subversion/config needs some manual changes as described
>> here
>>
>>
>> http://stackoverflow.com/questions/5671406/force-svneol-style-native-
>> on- the-server
>>
>> which sets the property at the initial checkin of each file, or we
>> need to do  one additional SVN commit to set that property, which
>> I've just done in  r22809.
>>
>> Note: For most of our *.h / *.c files I've also done this manually in
>> e.g.  r20217 or r18959, which explains why we didn't have any trouble
>> with those  files and line endings. I strongly suggest for every
>> developer to modify one's  own ~/.subversion/config to set
>> svn:eol-style=LF for *.h, *.c so that we  continue with a consistent
>> setting of the line endings.
>
> 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.
>
> For a discussion of the eol-style property see
>
> <http://svnbook.red-bean.com/en/1.7/svn.advanced.props.file-portability.html#svn.advanced.props.special.eol-style>. 
>
>
>             Mike
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Mike,

At first sight it would make sense indeed to set native eol style on 
files, so that native files don't get confused. The key to our decision 
to use the LF EOL style lies in the same requirement: make sure native 
tools don't get confused.

If you are now confused, let me explain: GnuCash is a program that 
originated on linux. The Windows build was added much later. This 
Windows build uses the same toolchain as on linux, but ported to Windows 
(autotools + gcc roughly). And even though this all runs on Windows 
natively, internally it shows these tools originally were written for 
linux. And one of the issues with these tools is that they are not 
completely EOL style agnostic. Mostly, but not completely.

Over the years this has popped up in various small corner cases breaking 
the build. My most recent issue I remember was with the AC_CONFIG_FILES 
macro in configure.ac. For readability I had inserted some empty lines 
in there. Worked perfectly on linux, but caused the build to fail on 
Windows (before I fixed the EOL issue in git). Clearly on Windows the 
line was no longer considered an empty line, but a line containing one 
character CR. Forcing a line-ending style of LF on these files fixed the 
problem.

Like that there are several small corner cases that tend to bite you 
when you least expect it. To avoid these tool chain hickups, we decided 
to force a line ending style we know to make the build work. As you can 
see this is a totally different  motivation than the svn article, which 
is only concerned about checking in lots of EOL differences. That is 
important as well, and is equally taken care of by our policy.

To be completely fair, it may not be necessary for *all* files to force 
a checked out line ending style. Only the ones that are known to 
potentially cause issues, or more broadly those files that have to be 
processed by a tool before distribution (like source files that have to 
be compiled, template files that are processed with sed or perl,...). In 
that sense the javascript files may not have required a force EOL style. 
It has become a habit though to do so to prevent any unexpected things 
to happen in the future.

The only disadvantage of our chosen EOL style I see on Windows is that 
Notepad doesn't handle the files properly. Any other Windows text editor 
I have used to process the gnucash code handles the EOL's just fine.

Geert