我应该如何修复“svn：行结束样式不一致”？
当我运行“svn propedit svn:ignore”时。 在我的 svn 存储库的根目录中，我收到此错误： svn：行结束样式不一致
我尝试运行此脚本： http://blog.eflow.org/archives /130 运行 dos2unix 并在所有文件上设置 eol-style，但是这个问题仍然存在。 知道可能出什么问题吗？
When I run "svn propedit svn:ignore ." at the root of my svn repository, I get this error:
svn: Inconsistent line ending style
I have tried to run this script: http://blog.eflow.org/archives/130 which runs dos2unix and sets the eol-style on all of the files, however this problem still persists. Any idea what could be wrong?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（22）
就我而言，
svn:eol-style属性是在文件上设置的。并且“文件的某些行由 UNIX 行结尾（LF 字符）分隔，而其他行则由 DOS 样式行结尾（CR+LF 字符）分隔”。 这里是对此问题的另一个详细讨论。
Notepad++ 中的
“编辑”->“EOL 转换”->“Windows 格式”为我解决了这个问题。In my case,
svn:eol-styleproperty was set on a file.And "some lines of the file were separated by UNIX line endings (LF character), while others were separated by DOS-style line endings (CR+LF characters)". Here is another detailed discussion of this problem.
"Edit"->"EOL Conversion"->"Windows format"in Notepad++ solved the issue for me.我收到此错误，但它最终成为一个缺少最后一个谎言结尾（最后一行不完整）的文件。
通过在 VI 中打开文件并保存来解决此问题。
I got this error, but it ended up being a file missing the last End-of-lie( incomplete last line).
Correcting this by opening the file in VI and saving it solved it.
该脚本是否确实触及了每个文本文件（假设您确实安装了 dos2unix，否则这就是原因......）？
我能想到的其他事情是检查所有文件的 mime 类型是否设置正确（您没有以某种方式标记为签入的文本文件的二进制文件，也许？）。
也就是说，如果您处于多操作系统环境中，我认为将 svn:eol-style 设置为 CRLF 不是一个好主意，如上面的博客文章中所述如果您正在共享和编辑文本文件操作系统之间。 因为如果你这样做，在 Windows 中看起来不错的文件在 Unix 中却充满了控制字符。 最好使用“native”作为 EOL 样式。
Did the script definitely touch each and every text file (assuming you do have dos2unix installed, otherwise that'd be why...)?
The other things I can think of is to check that all files have their mime-type set correctly (you don't have a binary file that's somehow marked as a text file checked in, perchance?).
That said, if you are in a multi-OS environment I consider it not a good idea to set svn:eol-style to CRLF as described in the blog post above if you are sharing and editing text files between OSs. Because if you do it that way, the files that look OK in Windows are littered with control characters in Unix. Better to use 'native' as the EOL style.
如果只发生一两个文件，您还可以打开该文件，将内容复制并粘贴到新文件（使用普通文本编辑器），然后保存。 然后可以添加该文件（重命名或移动以使其成为正确的名称）。
If it only happens with one or two files, you can also open the file, copy and paste the content to a new file (with a normal text editor), and save it. This file can then be added (rename or move to make it the correct name).
我的问题是我在 Visual Studio.NET 中得到了这个。 为了解决这个问题，我将文件的所有文本复制到记事本中，并将其从记事本保存为“xxx.aspx”或任何正确的文件名。 然后在 Visual Studio 中，系统提示我重新加载更改的文件，瞧，出现一个对话框，询问我是否要规范化行结尾。 问题解决了。
My problem was that I was getting this in Visual Studio.NET. To fix it, I copied all the text of the file into notepad and saved it from Notepad to "xxx.aspx" or whatever the proper file name is. Then in Visual Studio, I was prompted to reload a changed file, and voila - a dialog box asking me if I would like to normalize my line endings. Problem solved.
通过 cygwin运行
为我解决了这个问题。
Running
via cygwin fixed this for me.
Subversion 不会抱怨任何文件的内容，而是抱怨 svn:ignore 属性的内容。 解决此问题的一种方法是简单地使用 svn propdel 删除 svn:ignore 属性，然后重新创建它。
如果
svn:ignore中有很多行，另一种方法可能会更容易：在 a 中获取 svn:ignore 的值
像这样的临时文件：
<代码>svn
propget svn：忽略。 > temp
temp中的行结尾file
设置 svn:ignore 的值来自固定文件，例如
这个：
svn propset svn:ignore -Ftemp .
Subversion is not complaining about the content of any file, but about the content of the svn:ignore property. One way to fix this is to simply delete the
svn:ignoreproperty withsvn propdeland then recreate it.Another way which may be easier if you have a lot of lines in your
svn:ignore:fetch the value of svn:ignore in a
temporary file like this:
svnpropget svn:ignore . > temp
tempfile
set the value of svn:ignore from the fixed file like
this:
svn propset svn:ignore -Ftemp .
就我而言，我是在 Windows 中进行编辑的。
修复方法：
这样就完成了。
In my case I was editing in Windows.
To fix:
This did it.
vi 没有向我显示错误的行，因此我从注释部分删除了行尾，读取它们（直到 END）并保存文件。 之后它就起作用了。
注意：在调整 revprop 文件之前对其进行备份。 如果你放弃它，就不会回头
vi didn't show me the bad line so i removed the end of lines from the comment section, readded them (up to END) and saved the file. it worked after that.
NOTE: backup you revprop file before tweaking it. if you turf it, no going back
在 NetBeans 中，您可以使用“显示和更改行结尾”插件。
安装并重新启动 NetBeans 后，行结束样式将显示在状态栏的右侧。 您可以单击它并选择要将文件转换为的结尾。
In NetBeans you can use the "Show and change line endings" plugin.
After installing it and restarting NetBeans, the line ending style is shown at the right side of the status bar. You can click it and select the ending you want to convert the file to.
在对几个文本文件进行一些修改后，我出现了问题，仅添加
\n来分隔某些行，而通常\r\n终止每一行。 因此，解决方法是使用 Notepad++查找
([^\r])\n并替换为
$1\r\n。这样行尾字符在各处都是一致的。
The problem occurred for me after some modifications in several text files was made such that only
\nwere added to seperate certain lines, whereas normally\r\nterminate every line. So, the fix was to use Notepad++ tofind
([^\r])\nand replace with
$1\r\n.This way the end of line characters were consistent everywhere.
正如上面“Marius Matioc”所建议的那样，这将是简单而快速的修复
1.在Notepad++中打开文件
2.编辑菜单-> EOL 转换 -> Unix
3.保存
4.编辑菜单-> EOL 转换 -> 视窗
5.保存
As 'Marius Matioc' suggested in above, would be easy and quick fix
1.Open file in Notepad++
2.Edit menu -> EOL Conversion -> Unix
3.Save
4.Edit menu -> EOL Conversion -> Windows
5.Save
如果你在进行propedit时得到它，那么在我看来，SVN更多地抱怨你用于属性的文本文件的格式！
您使用的是哪个操作系统？ 您使用哪个编辑器进行推广？ 如果 propedit 命令仍然启动编辑器，我将使用该编辑器来检查其中有哪些行结尾（vi 执行此 IIRC）。
If you get it while doing the propedit, then it seems to me more that SVN is complaining about the format of the text file you're using for the properties!
Which OS are you on? Which editor are you using to propedit? If the propedit command still fires up an editor, I would use this editor to check which line endings are in there (vi does this IIRC).
这困扰了我很长时间，因为我是一个使用 SVN 的多系统团队。
我制作了这个有用的应用程序，它可以导航带有子文件夹的文件夹，查找文本文件，并将所有 UNIX EOL 转换为 DOS EOL。
它是一款 AIR 应用程序，可在 Windows 和 Mac 上运行。
希望它有帮助
http://www.pippoflash.com/index.php/2012/06/11/svn-error-inconcient-line-ending-style-nightmare-solved-download-app/
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
http://www.pippoflash.com/index.php/2012/06/11/svn-error-inconsistent-line-ending-style-nightmare-solved-download-app/
Filippo
对于 mac osx，我的文件出现此错误，必须先使用 dos2mac 进行转换，然后再使用 mac2unix 进行转换。 一旦我这样做了，它就解决了行尾抱怨的问题。
For mac osx, I got this error for a file and had to convert it using dos2mac and then mac2unix. Once I did that it fixed the issue for the line endings complaining.
要使用 perl(1) 将 Windows 行结尾一致地转换为 UNIX 行结尾：
要从 UNIX 转换回 Windows：
To consistently convert Windows to UNIX line endings using perl(1):
To convert from UNIX back to Windows:
我在 Windows 机器上通过 ant 任务运行 javadoc 时遇到了同样的问题。
我通过在 javadoc ant 任务下面添加
I had the same problem when running javadoc via an ant task on a Windows machine.
I fixed it by adding
<fixcrlf srcdir="${dir.javadoc}" eol="dos"/>below the javadoc ant task.我在以前运行良好的存档中遇到了同样的问题。 在notepad++中，我选择将格式转换为UTF-8。 这对我有用。
I had a same problem in a archive that was working well before. In notepad++, i've chosen convert format to UTF-8. This worked for me.
当我尝试在 emacs 中使用
svn propset eol-style:nativePHP 文件时，我收到了同样的错误消息，所以希望这能帮助解决这个问题的人。我有类似以下内容：
其中
^M是单个字符（插入符转义符用于回车）。解决方法是将该行更改为等效行：
注意双引号而不是单引号！
I got the same error message when trying to
svn propset eol-style:nativea PHP file in emacs, so hopefully this will help someone out who reaches this question.I had something like the following:
Where
^Mis a single character (caret escape for carriage return).The fix was to change that line to the equivalent:
Note the double quotes instead of single quotes!
就我而言，发生错误是因为文件的编码为“UCS-2 LE BOM”。 ANSI 文件没问题。 我检查了所有文件中的行结尾，它们都是正确的。
似乎（至少在我的 SVN 版本中）宽字符文件有时无法正确识别。
最简单的解决方案是删除“svn:eol-style”属性。
In my case the error occurred because the file had the encoding "UCS-2 LE BOM". The files with ANSI were ok. I checked the line endings, in all files they were correct.
It seems that (at least in my SVN version) wide char files are sometimes not recognized properly.
The simplest solution is it to remove the "svn:eol-style" property.
对我来说，问题是编码是 UTF-16 BE BOM。 我必须使用 Notepad++ 将其转换为 UTF-8 BOM（编码 -> 转换为 UTF-8 BOM）。
For me the Problem was that the encoding was UTF-16 BE BOM. I had to convert it to UTF-8 BOM using Notepad++ (Encoding -> Convert To UTF-8 BOM).
我还有一个案例。 文本文件采用 Unicode。
示例： WebConversationStateTest.cs
将 Unicode (UTF-16) 转换为 UTF-8 后一切正常。
I have yet another case. Text file was in Unicode.
Example case: WebConversationStateTest.cs
After converting Unicode (UTF-16) to UTF-8 everything was ok.