我们正在考虑从版本控制系统的签出/编辑/签到样式转向Subversion，在评估期间我们发现当您在TortoiseSVN中执行更新操作时（可能在任何Subversion客户端中） ？），如果需要应用于您正在编辑的文件的存储库中的更改不会导致任何冲突，那么它们将自动/静默合并。
这让我们有点害怕，因为这种合并可能会产生任何编译错误，但至少会引入一些可能无法轻易检测到的逻辑错误。
非常简单的示例：我正在使用C＃方法在方法的后半部分更改某些逻辑，而其他人则在方法开始时更改变量初始化的值。另一个人的改变不在我正在处理的代码行中，因此不存在冲突;但是可以大大改变方法的输出。
我们希望情况是，如果需要进行合并，那么将显示两个文件，并且至少会显示一个简单的接受/拒绝更改选项，这样至少我们知道某些东西已更改并可以选择是否会影响我们的代码。
有没有办法用Subversion / TortoiseSVN做到这一点？或者我们是否过多地坚持现在的工作方式，应该让它做到这一点......
答案 0 :(得分：13)
在常见问题解答中： How can I prevent Subversion from doing automatic merges?
- 在TortoiseSVN-＆gt;设置 - ＆gt; General-＆gt; Subversion配置文件中，点击编辑按钮。
通过添加
更改[helpers]部分diff-cmd = "C:\\false.bat"（注意双反斜杠）
创建包含两行
的文件C：\ false.bat@type %9 @exit 1
答案 1 :(得分：10)
这是TortoiseSVN的一个技巧：
How to turn off “auto-merge” in Subversion
svn.exe的诀窍是将svn外部差异工具设置为一个会不断失败的程序。
svn --diff-cmd=/bin/false
如果外部差异程序失败，svn断定冲突是无法解决的，不会合并。
答案 2 :(得分：6)
解决这个问题的最佳方法是教育开发人员。 在TortoiseSVN中进行更新后，它会显示受影响文件的列表。只需双击每个文件即可获得它们之间的差异。然后，您将能够看到您的版本与最新的存储库版本之间发生了哪些变化。
答案 3 :(得分：1)
我建议你应该学会使用自然的Subversion模型，如果可能的话。在实践中，我们发现冲突是罕见的，你所谈论的逻辑冲突类型几乎不存在（我不记得过去4年在我们的存储库中的实例）。
团队成员应在尽可能小的范围内签入更改（同时保持正确性），而不是将整天工作批处理以仅检查一次。这将减少踩到别人的工作的可能性。
如果您担心特定的更改，那么Subversion确实提供了一种锁定机制，可以阻止对文件进行其他更改。请参阅Red Book上的locking章节。
答案 4 :(得分：0)
这就是自动（单元）测试是分布式软件开发的基本部分的原因。在您给出的示例中，至少有一个单元测试应该在svn update上失败并提醒您错误。
记住Subversion是什么：版本控制系统，而不是完美的代码合并工具。