如何避免 Subversion 中的复杂合并？答案

【问题标题】：How do I avoid Complicated Merges in Subversion?如何避免 Subversion 中的复杂合并？
【发布时间】：2010-12-15 21:45:05
【问题描述】：

我是来自 Visual Source Safe (VSS) 背景的 Subversion (SVN) 新手。在 VSS 中，编辑文件的人会检出该文件，并阻止其他用户通过 Visual Studio 对其进行编辑。我知道 SVN 是一个并发模型，允许多人处理同一个文件，然后将更改合并在一起。我的问题是这样的：

避免让用户编辑同一个文件（编写大量代码）并面临复杂的更改合并或更糟糕的是编写大量代码却发现文件的最佳方法是什么？被其他用户锁定？
是否有办法在检索文件时通知用户该文件当前正在被其他用户编辑或当前被其他用户锁定？

其他细节：

使用 VisualSVN 服务器作为 SVN 服务器。
使用 TortoiseSVN 和 AnkhSVN 客户端。

【问题讨论】：

感谢大家的所有建议，让我直截了当。
晚了一年，但我真的不得不推荐阅读SVN手册。它以随意、务实的方式编写，读起来像是一个广泛的 SO 答案。

标签： svn version-control tortoisesvn ankhsvn

【解决方案1】：

我也是 Visual Source Safe 的前用户。合并曾经让我发疯，直到我意识到这不是技术问题，而是人员问题。在使用 VSS 时，大多数开发人员会在必须签入代码之前尝试尽可能多地完成工作。这种行为是导致复杂合并的原因。

以下几点可以缓解这种情况：

在开始之前始终更新您的工作副本
经常检查。这将使代码更改更小，更容易自动合并
不要让工作代码处于未选中状态
如果更改需要几天或更长时间，开发人员应创建自己的分支

这些东西帮助很大，尤其是在我工作的团队越来越大的情况下。从 VSS 复制锁定行为是一个非常糟糕的主意，并且会导致更多问题。只需拥抱新的工作流程。

如果你还想用一个工具，那我建议你看看SVNMonitor。

【讨论】：

感谢您推荐 SVNMonitor。
你错过了一件重要的事情，它让分支成为一种工作的乐趣。经常更新...人们已签入您的分支机构的主干更改。与您在第 1 点中所说的相同。对你的分支做同样的事情..它不应该被区别对待。如果您经常使用人们每天检查到主干的更改来不断更新您的分支，那么您最终不会遇到任何合并地狱，因为您的分支中的代码几乎是最新的或接近最新的因为你一直虔诚地更新你的分支！每天的小痛苦让生活变得轻松

【解决方案2】：

我想建议采用不同的方法来使用颠覆。

您应该经常获得更新。
您还应该尽早并经常入住。

使用这种方法，合并通常很少发生并且会自动发生。在发生冲突的情况下，这些通常较小。

【讨论】：

【解决方案3】：

我在之前从基于锁的系统转到 SVN 的地方遇到的几点。

尝试在 SVN 中复制锁定-编辑-解锁行为并不是一个好主意，因为它的设计方式是您不需要那样工作。 SVN 使用的合并算法非常好，我只遇到过少数需要在合并期间进行手动干预的情况。处理同一个文件的两个人实际上会接触同一行是非常罕见的，而后者通常是唯一需要人工干预的时候。

SVN 真正设计用于经常从主干或当前分支进行更新的环境。如果您必须进行长期工作或更改文件中的大量代码的工作，您最好使用分支来完成工作并将其重新合并。是的，您必须进行一些合并时不时会感到疼痛，但它比使用非设计为以这种方式工作的系统所带来的痛苦要少得多。

如果您不尝试将 SVN 用作“本机 SVN”，而是将其用作具有不同名称的 VSS，那将是痛苦的，而且不值得麻烦。熟悉新范例后，您会惊讶地发现，与旧的“在任何给定时间只有一个用户编辑给定文件”例程相比，以这种方式工作要好得多。

【讨论】：

【解决方案4】：

首先，如果可能的话，避免在不签入文件的情况下编写“大量代码”可能是明智之举。如果你有一个好的单元测试套件（如果没有，为什么不呢？:)，那么只要你在绿条上签到，频繁提交是最好的。

然后，如果您确实有必要进行需要很长时间的更改，则值得定期发送svn update 以尽可能与主干保持同步。 Subversion 在合并方面相当可观（与 VSS 相比），并且可以很好地处理大部分内容。

任何它无法处理的东西，都会进入冲突状态，让您使用您选择的合并工具解决冲突（我推荐WinMerge，这是王牌）。

【讨论】：

【解决方案5】：

您可能希望使用旧 VSS 样式锁定模型的唯一情况是使用您想要版本化的二进制文件（MS-Word 文档等），但 SVN 无法自动合并来自多个源的更改。

【讨论】：

【解决方案6】：

没问题。使用 Tortoise SVN，执行此操作 ...

在 Windows 资源管理器中，右键单击文件。
选择“Tortoise SVN”，然后选择“获取锁定...”
在“锁定文件”对话框中，填写在你锁定的原因。
点击确定。

【讨论】：

技术上是对他问题的正确答案，但不是解决问题的好方法。正确使用 SVN 时，几乎没有理由使用锁。
我们已经探索过使用 lock 命令，但仍然存在其他用户未收到有关文件状态的通知的“问题”。

【解决方案7】：

虽然 SVN 有一个 lock 命令，但最常见的 SVN 使用方法是乐观的锁定方法。

这意味着您和我可以编辑同一个文件而不必太担心（大多数时候我们不会因为我们要处理项目的不同部分）。如果我首先提交对文件的更改，那么您的提交尝试将失败。届时 SVN 会通知您。

然后您必须运行“更新”命令，该命令（很可能）会自动将我提交的更改与您的本地更改合并，然后您的下一次提交尝试将通过。

为了避免在这种乐观的方法中遇到麻烦：正如其他人建议的那样，经常提交，不要一次提交太多！

【讨论】：

【解决方案8】：

SVN 是一种并发模型，允许多人处理同一个文件，然后将更改合并在一起。

我认为更多的是处理由一堆或多或少的独立文件组成的同一个项目。处理同一个文件并合并结果当然是可能的，并且时不时会发生，但这绝对不是默认/所需的操作模式。所以：

经常更新。
经常提交。
避免大类/文件（1000 行太多了）。这也有额外的好处:-)

【讨论】：

【解决方案9】：

我会花一些时间学习“签到舞”

这是一个dime cast。

网络上也有多篇关于此以及如何减轻痛苦的文章。

【讨论】：

【解决方案10】：

简答：

经常更新。早点入住，经常入住。如果您的工作时间更长（超过一两天），请考虑创建一个功能分支。
没有。

答案有点长：

如果多个开发人员对同一个文件进行了“大量更改”，那么您的开发人员的工作方式或功能分布在不同文件中的方式都会出现问题。我一直在不同规模的团队中使用 CVS 和 SVN，而 IME 很少有合并成为真正问题的情况。（这些通常是对字符串、日志记录、错误处理等基本服务的更改，需要更改几乎所有代码。这种情况需要一些人工交互和计划才能顺利进行。）

【讨论】：

【解决方案11】：

我同意其他所有人的观点，尽可能早且经常地检查（并非总是可能）。如果你正在做一些复杂和新的事情，它可以在一个分支上完成——同样的规则也适用，尽早并经常提交，并且使用头部的代码使你的分支尽可能保持最新。

根据我们的经验，大多数人往往不会同时处理同一个文件或至少文件的同一部分（在 VSS 中您不能因此您的工作模式可能已经在这方面为您提供支持）。

还有一个关键 - 确保每个人都使用相同的规则来使用制表符/间距、布局和格式，无论如何这是一个很好的做法，但越一致，你就越不可能找到“差异” " 在实际上并不存在的代码文件之间。

此外，我建议您考虑持续集成，即拥有一个构建服务器，这在确信您提交的代码将在“干净”环境中构建的信心方面提供了相当大的好处，并且如果您配备了适当的测试，将让您更加确信它仍然有效 - 即使在复杂的合并过程之后。

我们使用TeamCity，我们发现它非常好 - 但还有其他的。

【讨论】：

对持续集成构建服务器的“追求”是引导我走上使用颠覆之路的原因。 CruiseControl.NET 是我们用来构建构建服务器的原型。