什么会导致SVN更新错误合并？

几天前，我收到一封电子邮件，其中有人在构建我在谷歌代码上的Delphi项目时遇到了问题。项目文件和一个DFM文件在他用我签入的一些更改进行更新后被屏蔽。我们来回地聊了一会儿，追根溯源到他所说的SVN投入了额外的东西。他删除了文件并再次运行更新，运行正常

---

我以前从未见过这个问题，我也无法复制或验证任何一个问题。没有与其他用户发生任何更新冲突，因为我是唯一拥有存储库写入权限的用户。所以我想知道是什么导致了这一切。这是SVN的已知问题吗？有没有办法防止这种情况发生？

假设他或他的本地系统设法破坏了这两个文件

然后假设他进行了更新，发现一些东西不起作用。经过一番指指点点，他删除了带有本地mods的文件，运行update，然后gee。。。正确的文件

---

虽然奇怪的语法错误总是可能是编译器错误，而损坏的文件是

svn

错误，但通常有更平淡无奇的原因，我们有权威认为更简单的解释通常是正确的

如果DFM文件被Subversion视为文本，假设用户有本地更改，它将尝试合并。当存在冲突且Subversion无法解决冲突时，它将添加额外的细节以帮助您手动解决冲突，您将看到类似于

的文本“munged”文件是否包含“mine”或“theres”文本

如果是这样的话，他很可能把解决冲突的方法搞砸了，结果在不经意间犯下了他们或我的错误

或者完全有可能合并认为可以自动合并更改，因为它们位于文件的“不相关”部分，但对于SVN（或任何简单的自动合并过程）“不相关”只是指不重叠/不重叠的文件行

“Naiver”自动合并对文件内部的任何结构一无所知，因此可能很容易合并它认为不相关的更改，而实际上这些更改对彼此都有不利的副作用。在不确切了解“咀嚼”的性质的情况下，很难说清楚，尽管在这种情况下，提及“额外的东西”表明无意中承诺的“我的”或“他们的”修订似乎最有可能。
哪种德尔福版本？旧的Delphi版本存在错误，有时文本DFM文件会变成二进制文件

文件突然变成二进制文件会杀死任何源代码管理系统

--jeroen
您是否在多个平台上工作？您是否使用假定Unix行结束的编辑器（如某些cygwin工具？）

如果是这样，请检查您是否正确配置了eol样式属性。
我正在执行SVN更新，而SVN将DFM文件搞得一团糟。除了项目文件和DFM（表单描述）文件由IDE管理之外。它们以文本格式存储，但您通常不会像普通源代码那样手动编辑它们。我从来没有听说过IDE会损坏DFM文件，损坏的项目文件偶尔会发生，但并不经常发生。所以我觉得这个解释有点不太可能。我完全同意你的观点，但现在我们必须考虑出版偏见，也就是报道偏见。当然，这不太可能，但相互竞争的解释也是如此。我们正在将不可能发生的情况与其他不可能发生的情况进行比较，考虑到只有腐败才会被报告，腐败很少这一事实可能是一个危险的理由。我同意，他很可能在当地大肆宣扬腐败。“svn添加的额外内容”很可能是svn在识别本地冲突时将添加到工作副本中的版本文件中的冲突信息。解决冲突会让“多余的东西”消失。或者干脆删除它们，然后再试一次有趣的把戏。但是，在签入新的一批代码之前，我将失去使用OrtoiseSVN检查更改的能力。如果合并，则很容易损坏DFM文件，更改“不重要”的详细信息可能会导致组件顺序更改。天真的合并可能会把事情搞得一团糟。@Mason-你试过了吗？TortoiseSVN->Diff将显示更改（对我来说是这样，但我已将其配置为使用超越比较的功能），SVN不会显示差异（比如在提交后的电子邮件中），而是报告“二进制文件不同”。我用Delphi编写代码已经好几年了，但我猜它类似于.NETDesigner文件。就我个人而言，我不会为这种文件设置MIME类型（我只是建议一种可能的解决方案），因为如果我在更新自动生成和维护的文件后看到“合并”状态，这是一个很大的线索，事情可能会出问题：）如果不清楚：我不是建议将svn:MIME类型设置为安全特性，但考虑到大多数工具（向文件发送更改的详细信息）都使用svn或svnlook，这是一种有助于防止意外发送敏感数据的方法，而您并不希望这些数据被发送。例如，我们对svnserve authz和passwd文件进行了版本设置，尽管我在config目录上设置了authz，但我不希望我们的post-commit-email钩子通过电子邮件发送不同的更改。当然，任何具有适当授权的人都可以看到这些更改。同样，这不是一项安全措施，只是为了减少数据泄漏。2010年，因此这不是一个问题。它仍然可能是：如果SVN不正确支持unicode（或某个SVN客户端不支持），那么您将遇到麻烦