Op 24-02-13 00:23, Mike Alexander schreef:
--On February 23, 2013 5:07:47 PM +0100 Christian Stimming
<[email protected]> 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
[email protected]
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
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
