什么会导致 SVN Update 合并错误？
几天前，我收到一封电子邮件，来自某人，他在构建我在 Google Code 上的 Delphi 项目时遇到了麻烦。在他更新了我签入的一些更改后，项目文件和其中一个 DFM 文件被修改了。我们来来回回地聊了一会儿，并追溯到他所说的 SVN 加入了额外的东西。他删除了文件并再次运行更新，效果很好。
我以前从未见过这个问题，并且最终无法重现或验证任何问题。与其他用户没有任何更新冲突，因为我是唯一拥有存储库写入权限的用户。所以我想知道是什么原因造成的。这是 SVN 的已知问题吗？有没有办法阻止它发生？
I got an email a few days ago from someone who was having trouble building a Delphi project I have on Google Code. The project file and one of the DFM files were munged after he updated with some changes I had checked in. We talked back and forth a bit, and traced it down to what he said was SVN throwing in extra stuff. He deleted the files and ran Update again and it worked fine.
I've never seen this problem before, and I wasn't able to reproduce or verify any of it at my end. There weren't any update conflicts with other users, since I'm the only one with write access to the repository. So I'm wondering what could have caused this. Is this a known issue for SVN? Is there a way to keep it from happening?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
“munged”文件是否包含“我的”或“他们的”文本？
如果是这样，他可能搞砸了他的冲突解决方案，并最终无意中犯下了他们或我的rev。
或者完全有可能合并认为它可以自动合并更改，因为它们位于文件的“不相关”部分，但对于 SVN（或任何天真的自动合并过程）来说，“不相关”仅意味着在不相关的文件行中't/没有重叠。
“天真的”自动合并对文件内部的任何结构一无所知，因此可以轻松地合并它认为不相关的更改，而实际上这些更改会相互产生不利的副作用。在不准确了解“咀嚼”的本质的情况下，很难确定，尽管在这种情况下，对“额外内容”的提及表明，“我的”或“他们的”修订的无意提交似乎是最有可能的。可能。
Did the "munged" files contain "mine" or "theirs" text?
If so he probably mucked up his conflict resolution and ended up committing the theirs or mine rev inadvertently.
Or it's entirely possible that the merge thought it could auto-merge changes because they were in "unrelated" parts of the file, but for SVN (or any naive auto-merge process) "unrelated" simply means in lines of the files that don't/didn't overlap.
"Naive" auto-merge knows nothing about any structure internal to the file so may easily merge changes that it believes are unrelated when in fact the changes have adverse side effects on each other. Without knowing precisely the nature of the "munging" it's hard to say for sure, although in this case the reference to "extra stuff" suggests that inadvertent commital of "mine" or "theirs" revisions seems most likely.
哪个德尔福版本？较旧的 Delphi 版本存在缺陷，有时文本 DFM 文件会变成二进制文件。
文件突然变成二进制会杀死任何源代码控制系统。
——杰罗恩
Which Delphi version? Older Delphi versions had bugs in which sometimes text DFM files became binary.
Files suddenly becoming binary kill any source control system.
--jeroen
您在多个平台上工作吗？您是否使用假定 Unix 行尾的编辑器（如某些 cygwin 工具？）
如果是这样，请检查您是否正确配置了 eol-style 属性。
Are you working on multiple platforms? Are you using editors that assume Unix lineendings (like some cygwin tools?)
If so, check if you configured the eol-style property properly.
我正在执行 SVN 更新，SVN 用 <<<<<.mine 搞乱了 DFM 文件，这是我以前从未见过的。在 Delphi 允许我打开项目之前，我必须手动删除这些修改。
I was perform a SVN update and SVN was mucking up the DFM files with <<<<<<<<.mine, which I'd never seen before. I had to manually delete those modifications before Delphi would allow me to open the project.
如果 Subversion 将 DFM 文件视为文本，假设用户进行了本地更改，它将尝试合并。如果存在冲突并且 Subversion 无法解决它们，它会添加额外的详细信息来帮助您手动解决冲突，您将看到类似
<<<<<<<<<<< .mine这当然会在 Delphi 中出现。也可能是 Subversion 自动进行了合并，这不会发生冲突，但会导致 DFM 文件损坏。您没有看到问题的原因可能是因为您没有进行本地更改，因此不需要合并。删除或恢复文件会将工作副本重置回 BASE，因此任何更新都不需要进行合并。
一种解决方案：如果您有不应被 Subversion 合并的文本文件，则设置 svn:mime-type 为适当的非文本值，它会将其视为二进制，并且不会'不要尝试合并。您将需要手动修复该问题。顺便说一句，如果您需要在 Subversion 中存储敏感文本文件并且不希望差异显示内容，这也是一个很好的提示:)
If the DFM file was treated by Subversion as text, assuming the user had local changes, it will attempt a merge. Where there are conflicts and Subversion can't resolve them, it will add extra detail to help you manually resolve the conflicts, you will see text like
<<<<<<< .minewhich of course will bork in Delphi. It could also be that Subversion did a merge automatically, which didn't conflict, but lead to a corrupt DFM file.The reason why you didn't see the problem was probably because you didn't have local changes, so no merge was necessary. Deleting or reverting the files resets the working copy back to BASE so any update won't need to do a merge.
One solution: If you have text files which should not be merged by Subversion, then set the svn:mime-type to an appropriate non-text value, and it will treat it as binary, and won't attempt a merge. You will be required to manually fix the problem. Incidentally, this is also a good tip if you need to store sensitive text files in Subversion and don't want diffs showing the content :)
假设他或他的本地系统设法破坏了这两个文件。
然后假设他更新并发现事情不起作用。经过一番指指点点后，他删除了带有本地 mods 的文件，运行更新，天哪……正确的文件！
Entia non sunt multiplicanda praeter necessitatem。
虽然奇怪的语法错误总是有可能是编译器错误，而损坏的文件是
svnbug，但通常还有更平淡无奇的原因，我们在 奥卡姆的威廉权威认为，越简单的解释通常是正确的。Suppose he or his local system managed to mangle the two files.
Then suppose he updates and finds things not working. After some finger-pointing he deletes the files with, ahem, local mods, runs update, and gee ... the right files!
Entia non sunt multiplicanda praeter necessitatem.
While it is always possible that a strange syntax error is a compiler bug and a corrupted file is an
svnbug, there are usually more prosaic reasons, and we have it on William of Ockham's authority that the simpler explanation is usually the correct one.