我几天前收到了一封电子邮件，其中有人在构建我在Google Code上的Delphi项目时遇到了问题。在更新了我已经检查过的一些更改后，项目文件和其中一个DFM文件被发出警告。我们来回谈了一下，然后追溯到他说的是SVN投入额外的东西。他删除了文件并再次运行Update，它运行正常。
我之前从未见过这个问题，而且我无法在我的最后重现或验证任何问题。与其他用户没有任何更新冲突，因为我是唯一一个对存储库具有写访问权限的用户。所以我想知道是什么导致了这一点。这是SVN的已知问题吗？有没有办法阻止它发生？
答案 0 :(得分：5)
如果Subversion将DFM文件视为文本，假设用户进行了本地更改，则会尝试合并。如果存在冲突并且Subversion无法解决它们，它将添加额外的细节以帮助您手动解决冲突，您将看到<<<<<<< .mine这样的文本当然会在Delphi中出现问题。它也可能是Subversion自动进行合并，但没有冲突，但会导致损坏的DFM文件。
您没有看到问题的原因可能是因为您没有本地更改，因此不需要合并。删除或还原文件会将工作副本重置为BASE，因此任何更新都不需要进行合并。
一个解决方案：如果你有不的文本文件被Subversion合并，那么将svn:mime-type设置为适当的非文本值，它会将其视为二进制，并且不会尝试合并。您将需要手动修复问题。顺便提一下，如果您需要在Subversion中存储敏感文本文件并且不希望显示内容的差异，这也是一个很好的提示:)
答案 1 :(得分：3)
假设他或他的本地系统设法破坏了这两个文件。
然后假设他更新并发现不起作用的东西。一些指点后，他删除文件，咳嗽，本地mods，运行更新，和gee ...正确的文件！
Entia non sunt multiplicanda praeter necessitatem
虽然奇怪的语法错误总是可能是编译器错误而损坏的文件是svn错误，但通常有更多平淡无奇的原因，我们在William of Ockham's权限上拥有它更简单的解释通常是正确的。
答案 2 :(得分：1)
“munged”文件是否包含“我的”或“他们的”文本？
如果是这样的话，他可能会破坏他的冲突解决方案，并最终无意中将他们的或者我的版本投降。
或者完全有可能合并认为它可以自动合并更改，因为它们位于文件的“无关”部分，但对于SVN（或任何天真的自动合并过程），“无关”仅仅意味着在行中没有/没有重叠的文件。
“天真”自动合并对文件内部的任何结构都一无所知，因此可能很容易合并它认为不相关的更改，而实际上这些更改会对彼此产生不利的副作用。在不知道精确“沉思”的性质的情况下，很难肯定地说，尽管在这种情况下，对“额外的东西”的提及表明无意中“矿”或“他们的”修订似乎是最重要的可能的。
答案 3 :(得分：0)
哪个Delphi版本？较旧的Delphi版本存在错误，有时文本DFM文件变为二进制文件。
文件突然变成二进制文件会导致任何源控制系统崩溃。
- 的Jeroen
答案 4 :(得分：0)
你在多个平台上工作吗？您是否正在使用假定Unix线条的编辑器（如某些cygwin工具？）
如果是，请检查您是否正确配置了eol样式属性。
答案 5 :(得分：0)
我正在执行SVN更新，并且SVN正在使用＆lt;＆lt;＆lt;＆lt;＆lt;＆lt;＆lt;＆lt;＆lt;＆lt;＆lt; .mine来删除DFM文件，这是我以前从未见过的。在Delphi允许我打开项目之前，我不得不手动删除这些修改。