Thursday, November 20, 2008

Subversion Inconsistent line ending style error message

While trying to do an import of jboss 4.2.3.GA tonight, I've come across this error about 4 times so far.
svn: File 'jboss-4.2.3.GA/server/default/deploy/jbossws.sar/jbossws-context.war/index.html' has inconsistent newlines
svn: Inconsistent line ending style
svn: Your commit message was left in a temporary file:
svn: 'svn-commit.tmp'
Seriously, what the hell? Don't kill the entire commit with fail. Just give me the option to either fix the problem myself, fix the problem for me (default option and pick unix linefeeds) or finally give up. Additionally, why can't the client just do this check before getting 100 files into the commit? Grumble, why do you software developers make my life so difficult sometimes?

Tonight's fix:
Install dos2unix since OSX doesn't come with it (assuming you have MacPorts installed): sudo port install dos2unix
Then run it against any suffixes that need to be converted: find . -name \*.html | xargs dos2unix


Cassini said...

It means you have set the svn:eol-style property on a file, thereby asking Subversion to convert the file's line endings to some style,
but your file does not contain exclusively one EOL style. For example, maybe some lines of the file are separated by Unix line
endings (LF character) while others are separated by DOS-style line endings (CR+LF).

We had these kinds of line-ending problems with files from our programmers who use UltraEdit on Windows, because it has ridiculous
default settings which lead to this kind of nonsense. Perhaps your editor is similar.

Either that, or you've specified svn:eol-style on a file for which you did not mean to do so -- for a binary file perhaps?

Unknown said...

a) I've already set the svn:eol-style=native, that is why I'm seeing the problem in the first place. native should be the default, but sadly that doesn't seem to be the case. It isn't being applied for anything other than files which I intended.
b) If you read my posting, I'm talking about a 3rd party piece of software that I downloaded and am importing into svn. I do this for dealing with vendor branches.
c) It is nonsense and that is the point of my posting. The svn client should deal with this issue better.

Jorge Uriarte said...

Damn... I'm suffering this behaviour myself in this very moment!
Importing cmsms, which happens to have mixed line endings in lots of files :-P

Agreed, a command line option to force conversion would be fine...

Jin Kwon said...

Thank you. This is what I've searching for...
You looks good anyway.

Dominic said...

I agree, the "svn commit" should do a check in advance. It would probably slow down the operations a lot, but I'm willing to make that sacrifice.

After using dos2unix, if you still get "inconsistent line ending style", open the file and look for a single CR (old MacOS style). My dos2unix just ignores them (Ubuntu 9.04).

I had this problem when importing the source code of Nmap 4.68, where a "configure" script contained a comparison between a CR character and a '\r'. In this case, I assumed it really needed to keep the CR character for the test, so I removed the eol-style=native property for the commit.

Humpty Dumpty said...

I just found that if you don't have a CRLF line ending at the end of file SVN will still complain.

So, convert files using dos2unix and then edit the file directly by going to the end of the last line and putting in an extra CRLF.

I did all this using notepad++ which worked a charm.

Maria Sigal said...

open your file in notepad ++
go to Edit --> EOL converstion--> UNIX FORMAT or Mac FORMAt
this should solve such problems

Unknown said...

Thanks maria, that worked perfectly!

Anonymous said...

In the repositories I work most often with, I see usually this more from files being encoded oddly. i.e. UTF-8 without BOM or BOM but encoded as ANSI, stuff like that.

I agree, man....I'm currently importing 22,000 files from a vendor drop and I've started yelling at my computer by this point, lol. I also place some blame on text editor programmers. I mean, you're writing an entire text editor (even so far as to be geared towards code editing, in some cases), and it's that hard to figure out (or that low of a business priority) to design a decent encoding logic? I've written more robust encoding rules for Xbox UI widgets....

Yogananda said...

This bothered me for so long, working an a multi-system team with SVN.
I made this useful app, that navigates a folder with sub-folders looking for text files and converts all UNIX EOL to DOS EOL.
It is an AIR app, works on both Windows and Mac.
hope it helps


Unknown said...

Thanks for the help. I was able to open the file in question with vi on my terminal and I was able to spot the evil ^M character and eliminate it.