18

I'm completely stuck with an SVN error when committing 2447 files at once. I'm using TortoiseSVN (latest version) on Windows 7 64 bits.

The fact is that some files were created on Mac, and others on PC, so TortoiseSVN stopped the commit with an annoying Inconsistent line ending style error.

In the beginning, to solve this problem, I manually opened the incriminated file in NetBeans, added one blank space, removed it and saved the file so NetBeans converted properly all line ending characters, but it seems there are more than "some files" incriminated.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Epoc
  • 7,208
  • 8
  • 62
  • 66
  • 2
    I would try using `unix2dos` on a cygwin shell. – Kai May 24 '13 at 08:41
  • 1
    Write a small program that looks for mac style terminator and replaces them with windows style? Netbeans find&replace with regex might also be able to do that. – assylias May 24 '13 at 08:44
  • [Notepad++](http://notepad-plus-plus.org/) can also find & replace in multiple files at once and supports searching for `\r`, `\n`, etc. – Kai May 24 '13 at 08:47
  • I prefer the @assylias's solution. I created a regex which works almost : `\w\n$` - it select all Unix EOL chars, except that it select also the first character (`\w`) at the beginning... – Epoc May 24 '13 at 09:11
  • 2
    You can capture the w: `(\w)\n$` and replace with `$1\r\n` where $1 is the character. – assylias May 24 '13 at 09:32
  • Thank you it worked (after modifying it a bit for my needs) !! – Epoc May 24 '13 at 10:07

8 Answers8

26

Under Windows 7, you can use Notepad++ v5.6.8 to convert EOL characters:

Menu Edit → EOL Conversion → Windows / Unix / Mac

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Tuna
  • 2,937
  • 4
  • 37
  • 61
3

You can capture the w, (\w)\n$, and replace it with $1\r\n where $1 is the character.

Searching and replacing with NetBeans with this regex does the job.

My problem was that a custom script inserted wrong EOL characters (\n instead of \r\n) in these files).

(I answered my own question with @assylias's comment.)

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Epoc
  • 7,208
  • 8
  • 62
  • 66
  • If this works the best for you, why didn't you marked it as answer? – Simon Sobisch Aug 04 '16 at 06:00
  • @SimonSobisch: Probably because stackoverflow does not allow you to accept your own answer until 48 hours have passed, and it isn't worth most people's time to remember to go back and accept it once that is possible. – ToolmakerSteve Nov 29 '16 at 19:34
  • @ToolmakerSteve This is unlikely in this case as Epoc did accept an answer that was posted two weeks after his own one. I Just asked because he explicit wrote in his answer "this worked for me" but marked the answer with the most votes as "this worked for me". – Simon Sobisch Nov 29 '16 at 19:57
  • The most upvoted answer is much more simpler than the mine. – Epoc Nov 30 '16 at 15:14
3

In Notepad++, select menu View → Show Symbol → Show End of Line.

In the search box (Ctrl + F), select the Regular Expression search mode and search for the string:

[^\r]\n$

(translation: \n without a \r before it).

This will bring you directly the problem line(s) where you'll see the line ending with LF rather than with the pair CR-LF.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Dror Harari
  • 3,076
  • 2
  • 27
  • 25
  • Are you sure the dot after the character group is correct? AFAICS, this regex selects lines that contain `anything but a \r` followed by `anything` followed by `\n`. Shouldn't the expression be `[^\r]\n$`? – Fabian Streitel Apr 21 '15 at 07:14
  • Thanks, was not supposed to be there. This form found for me the line that ended with \n rather than the \r\n. Fixed – Dror Harari Apr 23 '15 at 22:30
  • my NP++ matches with `$\r\n` instead of `\r\n$` (counts the end of a line as the char *before* the line delimiter), just in case anyone's having issues – Hashbrown Aug 04 '16 at 02:38
2

If your line endings are all in order, it could be that your text file has a UTF-16 byte order mark (BOM).

You can fix that using Notepad++. Menu Encoding → Convert to UTF-8.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
jla
  • 6,904
  • 2
  • 36
  • 34
  • Nice catch! For some reason windows scheduler exports its tasks to xml files of `UCS2 LE BOM` encoding :| tortoise didn't like that very much, apparently. After going to `UTF` scheduler was still able to import them back so this works for me – Hashbrown Aug 04 '16 at 02:36
1

I opened the project properties window by right-clicking the file explorer while browsing the repository I wanted to edit, and then selected:

TortoiseSVN → Properties → New... → EOL → As is (no specific EOL) → OK.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
iggy12345
  • 1,233
  • 12
  • 31
0

In Vim or gVim under Windows, the broken files all showed ^M at the end of each line.

To fix it: :s/\r//g to remove the broken extra line endings.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Fabian Streitel
  • 2,702
  • 26
  • 36
0

In relation to the post from Fabian Streitel, actually the Vim regular expression should be :1,$s/\r//g to cover the entire file.

Another way on Unix-like systems is using sed:

sed -i '-es/\r//g' <your_file>
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Rolland Dudemaine
  • 71
  • 1
  • 5
  • 1
    Don't refer to an answer as "just above." They are ordered by score, so what's "just above" can change. Also, this should be a comment on that answer, not a separate answer, if it's just a correction. You should clarify your answer, and either make it standalone or delete it. – Keith M May 08 '18 at 21:33
  • Related (currently at 41 reputation points): *[Why do I need 50 reputation to comment? What can I do instead?](https://meta.stackexchange.com/questions/214173/why-do-i-need-50-reputation-to-comment-what-can-i-do-instead)* – Peter Mortensen Aug 12 '21 at 11:21
0

To solve the problem with different line endings, you can set the Subversion (SVN) property as follows:

svn propset svn:eol-style native my_file

Although this will solve the line endings problems and make merging easier, it will mean that blame will show the person adding the EOL-style as the changer of all lines, and it also means that your working files will end up getting copied into a temporary folder when doing a diff.

The blame issue can be solved afterwards by doing this:

svn blame my_file -x "--ignore-space-change --ignore-eol-style"
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131