Rationale for line-ending recommendation?
Sat Dec 20 16:30:00 GMT 2008
* On Fri, Dec 19, 2008 at 03:42:34AM -0600 Gary R. Van Sickle wrote:
> > From: Spiro Trikaliotis
> > Oh, and Subversion is problematic, too. Because the SVN
> > developers decided to handle line endings on their own using
> > libapr, opening files in binary mode and reading and writing
> > CR, LF or CR/LF on their own,
> This is the right way to do things...
I hope you are ironic here, right?
> > on Cygwin, SVN is hard-coded to
> > *nix line endings. This is not nice. Note that this approach
> > will also fail badly if you mount parts of your system in
> > textmode, and parts in binmode.
> > Because of this, I am using an SVN version which I compiled
> > myself with a patched libapr.
> ...I'm not following this. Are you talking about the SVN repository, or the
> clients, or...? What's the issue?
You are right, I was not specific enough. I never tested an SVN server
on Cygwin, thus, I can only talk about the client side.
If you check out some files which are set to CRLF=native, Cygwin's SVN
checks them out with LF line ending (as SVN handles the endings on its
own, and libapr tells it that Cygwin == Unixoid == LF).
Now, if you edit a file of this using some tool that
1. does not have problems with the LF endings, but
2. generates CR/LF endings on new lines
(like, for example, MSVC does, but also some other tools)
then SVN cannot check in that file. It complains that the file has
"mixed line endings". Yes, that's right, but why does SVN care?
Even commands like "svn diff" behave erratically.
You have to use d2u in order to get this file checked in. This is really
Note: In my opinion, this is clearly an SVN/libapr problem, not a Cygwin
> I know CVS had some problems with the
> dreaded \n/\r\n issue back in the day, but I wasn't aware of similar
> Subversion issues.
The CVS issue was a mere cosmetical one, while the SVN one is a real
> > Other than that, I never had any problems with the CR/LF line endings.
> Bash has some known problems in this area, but there's a Cygwin-specific fix
> (that unfortunately is off by default) which hopefully will get accepted
> upstream sometime in the next century.
But this fix is in bash, right? So, it does not have a CR/LF issue in
Cygwin, as I said. ;)
> > Thus, many programmers do not care about the "right" mode.
> Well, better stated, they assume they can treat all files - text,
> executables, jpegs, whatever - as if they were Unix-formatted text files.
> Of course, they're not, hence problems ensue.
Well, it is hard to test something against problems that are unlikely to
occur at all in your environment, right? Of course, you can generate
artificial test cases for this. However, if you think about generating
these test cases, chances are high you would not do it wrong in the
Thus, while I think it is annoying that some tools have CR/LF problems,
I can understand WHY this happens.
Spiro R. Trikaliotis http://opencbm.sf.net/
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
More information about the Cygwin