【发布时间】：2009-05-27 18:51:14
【问题描述】：
当我运行“svn propedit svn:ignore”时。在我的 svn 存储库的根目录中，我收到此错误： svn：行尾样式不一致
我尝试运行此脚本：http://blog.eflow.org/archives/130，它运行 dos2unix 并在所有文件上设置 eol 样式，但此问题仍然存在。知道有什么问题吗？
【问题讨论】：
标签： svn line-endings
【发布时间】：2009-05-27 18:51:14
【问题描述】：
【讨论】：
-
在启用了资源管理器上下文菜单的窗口上使用 TortoiseSVN，您可以右键单击文件，然后导航到“TortoiseSVN”-->“属性”。将弹出一个对话框。如果您确定 EOL 在您的上下文中无关紧要，请查找“EOL”属性并以适当的方式对其进行编辑或直接将其删除。
-
对我来说，“Windows 格式”被禁用”。然后我转换为 unix，然后又转换回 Windows。它对我有用。@marius 解决方案。
-
就我而言，设置了
svn:eol-style属性。然而，（不知何故）它的价值变成了nativenative（而不仅仅是native）。当应用svn diff生成的补丁两次（使用svn patch）时，可能会发生这种情况。确切的错误是svn: E135001: Unrecognized line ending style。将属性值改回native解决了这个问题。 （在此处添加此评论，因为这是针对上述错误的最高 Google 搜索命中。）
就我而言，我在 Windows 中进行编辑。 修复：
- 在记事本++中打开文件
- 将行尾转换为 Unix（编辑菜单 -> EOL 转换 -> Unix）
- 保存
- 将行尾转换为 Windows（编辑菜单 -> EOL 转换 -> Windows）
- 保存
做到了。
【讨论】：
-
或者：用写字板打开，另存为UTF-8。
-
是的，有时它与行尾无关，svn 客户端实际上只是can't read the file 来检查结尾
Subversion 不是在抱怨任何文件的内容，而是抱怨 svn:ignore 属性的内容。解决此问题的一种方法是简单地使用svn propdel 删除svn:ignore 属性，然后重新创建它。
如果您的svn:ignore 中有很多行，另一种可能更容易的方法：
-
获取 svn:ignore 的值 像这样的临时文件：
svn propget svn:ignore . > temp - 修复
temp中的行尾 文件 -
从固定文件中设置 svn:ignore 的值，例如 这个：
svn propset svn:ignore -F temp .
【讨论】：
-
我最终不得不使用 svn propdel 并重新创建该属性。当我尝试您的第二个建议（propget > temp）时，我得到了与 propedit 相同的消息。谢谢！
-
我在特定文件上发现了一个“svn:eol”属性，其值为“native”。删除此属性为我修复了错误。
跑步
unix2dos [file]
通过 cygwin 为我解决了这个问题。
【讨论】：
-
一阶近似值很好，但 afaik unix2dos 不能修复也可能导致此问题的单个 CR。 （但很少见）。在这种情况下，您最好在执行 unix2dos 之前直接用“tr”过滤掉 CR
我的问题是我在 Visual Studio.NET 中得到了这个。为了修复它，我将文件的所有文本复制到记事本中，并将其从记事本保存到“xxx.aspx”或任何正确的文件名。然后在 Visual Studio 中，系统提示我重新加载已更改的文件，然后出现一个对话框，询问我是否要规范化我的行尾。问题解决了。
【讨论】：
-
喜欢这样愚蠢的简单解决方案。根本不在乎为什么会发生这种情况，只是希望它消失以获取文件。这适用于 Windows 上的 Eclipse 项目。
-
这对我来说非常有效，我不必为 svn:ignore 搞砸。万岁！
如果只有一个或两个文件发生这种情况，您也可以打开文件，将内容复制并粘贴到新文件（使用普通文本编辑器），然后保存。然后可以添加此文件（重命名或移动以使其成为正确的名称）。
脚本是否确实触及了每个文本文件（假设您确实安装了 dos2unix，否则这就是为什么...）？
我能想到的另一件事是检查所有文件的 mime 类型设置是否正确（你没有以某种方式标记为签入文本文件的二进制文件，也许？）。
也就是说，如果您处于多操作系统环境中，我认为将 svn:eol-style 设置为 CRLF 不是一个好主意，如上面的博客文章中所述如果您正在共享和在操作系统之间编辑文本文件。因为如果你这样做，在 Windows 中看起来还不错的文件在 Unix 中会被控制字符乱七八糟。最好使用“native”作为 EOL 样式。
【讨论】：
-
Timo，我很确定脚本触及了每个文本文件，实际上我在运行之前确实将脚本更改为“本机”。此外，我在签入时没有任何问题，只有在运行 propedit 命令时。这说明什么？
我收到了这个错误，但它最终是一个缺少最后一个 End-of-lie 的文件（最后一行不完整）。
通过在 VI 中打开文件并保存来解决此问题。
【讨论】：
vi 没有显示坏行，所以我从注释部分删除了行尾，读取它们（直到 END）并保存文件。之后就成功了。
注意：在调整之前备份您的 revprop 文件。如果你草皮它，就没有回头路
【讨论】：
如果您在进行 propedit 时得到它，那么在我看来，SVN 更多地抱怨您用于属性的文本文件的格式！
您使用的是哪个操作系统？您使用哪个编辑器来进行宣传？如果 propedit 命令仍然启动编辑器，我将使用此编辑器检查其中的行尾（vi 执行此 IIRC）。
【讨论】：
这困扰了我很长时间，我在一个使用 SVN 的多系统团队工作。 我制作了这个有用的应用程序，它导航一个带有子文件夹的文件夹，查找文本文件并将所有 UNIX EOL 转换为 DOS EOL。 它是一个 AIR 应用程序，适用于 Windows 和 Mac。 希望对你有帮助
菲利波
【讨论】：
对于 mac osx，我收到一个文件错误，必须使用 dos2mac 和 mac2unix 对其进行转换。一旦我这样做了，它就解决了行尾抱怨的问题。
【讨论】：
在对几个文本文件进行了一些修改后，我出现了这个问题，以至于只添加了\n 以分隔某些行，而通常\r\n 终止每一行。因此，解决方法是使用 Notepad++
找到([^\r])\n
并替换为$1\r\n。
这样，行尾字符在任何地方都是一致的。
【讨论】：
使用 perl(1) 一致地将 Windows 转换为 UNIX 行结尾：
perl -p -i.bak -e 's#\r\n#\n#go' my-file.txt
从 UNIX 转换回 Windows：
perl -p -i.bak -e 's#\n#\r\n#go' my-file.txt
【讨论】：
我在 Windows 机器上通过 ant 任务运行 javadoc 时遇到了同样的问题。
我通过在 javadoc ant 任务下方添加 <fixcrlf srcdir="${dir.javadoc}" eol="dos"/> 来修复它。
【讨论】：
我在以前运行良好的存档中遇到了同样的问题。在记事本++中，我选择了将格式转换为 UTF-8。这对我有用。
【讨论】：
当我尝试在 emacs 中 svn propset eol-style:native 一个 PHP 文件时，我收到了同样的错误消息，所以希望这会帮助解决这个问题的人。
我有类似以下的东西：
str_replace('</li>^M<br>', '</li>', $text);
其中^M 是单个字符（用于回车的插入符号转义）。
解决方法是将该行更改为等效的：
str_replace("</li>\r<br>", '</li>', $text);
注意双引号而不是单引号！
【讨论】：
在我的情况下，发生错误是因为文件的编码为“UCS-2 LE BOM”。带有 ANSI 的文件没问题。我检查了行尾，在所有文件中它们都是正确的。 似乎（至少在我的 SVN 版本中）宽字符文件有时无法正确识别。
最简单的解决方案是删除“svn:eol-style”属性。
【讨论】：
在 NetBeans 中，您可以使用“Show and change line endings”插件。
安装并重新启动 NetBeans 后，行尾样式显示在状态栏的右侧。您可以单击它并选择要将文件转换为的结尾。
【讨论】：
正如上面所建议的“Marius Matioc”，将是简单快速的修复 1.在记事本++中打开文件 2.编辑菜单 -> EOL 转换 -> Unix 3.保存 4.编辑菜单 -> EOL 转换 -> Windows 5.保存
【讨论】：