3

几天前，我收到了一封电子邮件，他在构建我在 Google Code 上的 Delphi 项目时遇到了麻烦。在他更新了我签入的一些更改后，项目文件和其中一个 DFM 文件被修改了。我们来回交谈了一下​​，并追溯到他所说的 SVN 投入了额外的东西。他删除了文件并再次运行更新，它工作正常。

我以前从未见过这个问题，而且我最终无法重现或验证任何问题。与其他用户没有任何更新冲突，因为我是唯一一个对存储库具有写入权限的用户。所以我想知道是什么原因造成的。这是 SVN 的已知问题吗？有没有办法阻止它发生？

4

6 回答 6

5

如果 DFM 文件被 Subversion 视为文本，假设用户有本地更改，它将尝试合并。如果存在冲突并且 Subversion 无法解决它们，它会添加额外的细节来帮助您手动解决冲突，您将看到文本<<<<<<< .mine当然会在 Delphi 中出现问题。也可能是 Subversion 自动进行了合并，这没有冲突，但导致 DFM 文件损坏。

您没有看到问题的原因可能是因为您没有本地更改，因此不需要合并。删除或恢复文件会将工作副本重置回 BASE，因此任何更新都不需要进行合并。

一种解决方案：如果您有不应该被 Subversion 合并的文本文件，则将svn:mime-type设置为适当的非文本值，它会将其视为二进制文件，并且不会尝试合并。您将需要手动解决问题。顺便说一句，如果您需要在 Subversion 中存储敏感文本文件并且不希望差异显示内容，这也是一个很好的提示：)

于 2009-10-13T00:37:33.423 回答
3

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

然后假设他更新并发现事情不起作用。经过一番指责后，他删除了文件，咳咳，本地模组，运行更新，哎呀......正确的文件！

Entia non sunt multiplicanda praeter necessitatem。

虽然奇怪的语法错误总是有可能是编译器错误，而损坏的文件是svn错误，但通常有更平淡的原因，根据奥卡姆的威廉的权威，我们认为更简单的解释通常是正确的解释。

于 2009-10-13T00:15:11.113 回答
1

“munged”文件是否包含“mine”或“theirs”文本？

如果是这样，他可能搞砸了他的冲突解决方案，最终无意中犯了他们的或我的 rev。

或者合并完全有可能认为它可以自动合并更改，因为它们位于文件的“不相关”部分中，但对于 SVN（或任何幼稚的自动合并过程）“不相关”仅意味着在不相关的文件行中't/没有重叠。

“天真的”自动合并对文件内部的任何结构一无所知，因此可以轻松地合并它认为不相关的更改，而实际上这些更改对彼此有不利的副作用。在不确切知道“修改”的性质的情况下，很难确定，尽管在这种情况下，对“额外内容”的提及表明无意中提交了“我的”或“他们的”修订似乎最有可能。

于 2009-10-13T00:38:52.953 回答
0

哪个德尔福版本？较旧的 Delphi 版本有错误，有时文本 DFM 文件会变成二进制文件。

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

——杰伦

于 2009-10-13T14:45:02.593 回答
0

您是否在多个平台上工作？您是否使用假定 Unix lineendings 的编辑器（如一些 cygwin 工具？）

如果是这样，请检查您是否正确配置了 eol-style 属性。

于 2009-10-13T15:20:20.337 回答
0

我正在执行 SVN 更新，而 SVN 正在使用 <<<<<<<<.mine 处理 DFM 文件，这是我以前从未见过的。在 Delphi 允许我打开项目之前，我必须手动删除这些修改。

于 2009-10-16T17:20:48.263 回答