我们正在考虑从版本控制系统的签出/编辑/签入风格转向 Subversion,在评估过程中我们发现,当您在 TortoiseSVN(可能还有任何 Subversion 客户端?)中执行更新操作时,如果存储库中需要应用于您正在编辑的文件的更改不会导致任何冲突,那么它们将自动/静默合并。

这让我们有点害怕,因为这种合并虽然不会产生任何编译错误,但至少可能会引入一些不易检测到的逻辑错误。

非常简单的例子:我正在 C# 方法中工作,更改方法后半部分的一些逻辑,而其他人则更改变量在方法开始时初始化的值。其他人的更改不在我正在处理的代码行中,因此不会发生冲突;但可以显着改变该方法的输出。

我们希望的情况是,如果需要进行合并,那么将显示这两个文件,并且至少会显示一个简单的接受/拒绝更改选项,这样至少我们知道某些内容已更改并且可以选择查看它是否影响我们的代码。

有没有办法用 Subversion/TortoiseSVN 来做到这一点?或者我们是否过于拘泥于目前的工作方式,而应该让它做它该做的事......

有帮助吗?

解决方案

解决这个问题的最佳方法是教育开发人员。在 TortoiseSVN 中进行更新后,它会显示受影响文件的列表。只需双击每个文件即可了解它们之间的差异。然后您将能够看到您的版本与最新存储库版本之间发生了什么变化。

其他提示

它在常见问题解答中:如何阻止 Subversion 进行自动合并?

  1. 在TortoiseSVN->设置->常规->Subversion配置文件中,单击编辑按钮。
  2. 改变 [helpers] 部分通过添加

      diff-cmd = "C:\\false.bat"
    

    (注意双反斜杠)

  3. 创建文件 C:\false.bat,其中包含两行

      @type %9
      @exit 1
    

这是 TortoiseSVN 的一个技巧:

如何关闭 Subversion 中的“自动合并”

svn.exe 的技巧是将 svn external diff 工具设置为一个会不断失败的程序。

svn --diff-cmd=/bin/false

如果外部 diff 程序失败,svn 会得出冲突无法解决的结论,并且不会合并它。

如果可能的话,我建议您应该学习使用自然的 Subversion 模型。在实践中,我们发现冲突很少见,并且您所说的逻辑冲突类型几乎不存在(我不记得我们存储库中过去 4 年的实例)。

团队成员应该以尽可能小的规模签入更改(同时保持正确性),而不是将一整天的工作分批只签入一次。这样就会减少踩到别人工作的可能性。

如果您担心所做的特定更改,Subversion 确实提供了 锁定 允许您防止对文件进行其他更改的机制。请参阅 红色的书 关于的章节 锁定.

这就是为什么自动化(单元)测试是分布式软件开发的基本部分。在您给出的示例中,至少一个单元测试应该在 svn update 上失败并提醒您该错误。

记住颠覆是什么:版本控制系统,而不是完美工作的代码合并工具。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top