subversion 中的合并是否比 Team Foundation System 中的更难？答案

【问题标题】：Are merges in subversion more difficult than in Team Foundation System?subversion 中的合并是否比 Team Foundation System 中的更难？
【发布时间】：2010-10-24 09:30:11
【问题描述】：

我习惯使用 TFS，我的公司现在正在为一个新项目切换到 SVN（主要原因是为了更好地将我们的 java 和 .Net 代码库合并到同一源代码控制下）。

我知道颠覆中的合并很难（Jeff mentioned this 在他最新的播客中）。

与 TFS 相比，颠覆有哪些问题？
如何缓解？（在颠覆的范围内，或者按照 Jeff 的建议，选择另一个源代码控制）

TFS 提供的一个强大功能是它的自动合并功能（在 TFS2008 中得到了极大的改进，虽然还不完美）。大多数合并不需要用户进行任何操作。 subversion 也一样吗？

更新 - 这里接受的答案只能来自在 TFS 和 subversion 中都经历过大合并的人，并且可以实际比较&对比两者。知道“合并颠覆是好的”或“TFS 是垃圾”并不能真正帮助我做出决定，因为它是主观的。如果您可以与其他替代品进行比较，那就太好了 - 这很有帮助。但我的重点是颠覆与 TFS。

我感兴趣的目标团队规模是 6-30 名活跃开发者。

更新 2 - 有没有人认为 SVN 中的合并实际上比 TFS 中更容易（考虑到工具）？

【问题讨论】：

看看我的回答。如果您需要任何澄清或更详细的信息，请发表评论。
关于您的更新，我会说“不”。

标签： svn version-control tfs merge comparison

【解决方案1】：

所有系统各有利弊。

但是一个有用的小提示（接近题外话）是外部强大的合并/差异程序通常非常有用。因此，无论您选择什么，请确保您有一个不错的 3 路合并工具，以便在自动化的东西出现故障时提供帮助。

BR 约翰

【讨论】：

【解决方案2】：

我在 TFS 和 Subversion 中都进行了大合并。 TFS 代码库是 SharePoint 应用程序的 1.5->2.0 分支，生产更改合并到 2.0 代码库中。 SVN 合并是将分支中的新功能合并到基线源中。

您已经熟悉 TFS，所以我将不再赘述，只是说 changesets 和 TFS 工具使该过程变得非常简单。由于取消删除问题，我们确实收到了 TF14087 错误，但很快就解决了。

在 SVN 中，该过程需要更多手动操作，因为我们必须针对 SVN 中文件的特定版本，并且 SVN 对文件进行了差异合并，这使我们无法获得在 TFS 中的变更集所体验到的灵活性（例如“不是 ChangesetA 中的所有更改，而是 ChangesetB 中的所有更改”）。当时我们没有合并跟踪，我们的源代码树也不是为了支持 SVN 合并跟踪的最佳实践而设计的。

我现在认为，如果您遵循 CollabNet 概述的最佳实践，那么使用 SVN 中的合并跟踪，该过程会变得相当简单。但请记住，TFS 是一款大型产品，拥有非常出色的 GUI 工具来管理您的源代码，而 SVN 更多地依赖于命令行，因此如果您习惯使用 GUI，这会使事情变得复杂。

【讨论】：

您的答案是此处被接受的答案的候选者。我明白你说 TFS 的工具是优越的，而 SVN 缺乏合并跟踪。用于颠覆的工具是否使用了 SVN 现在可以感知合并的事实？我可以像在 TFS 中那样简化合并吗？
svn merge --recordonly 将执行“阻塞更改”合并。它欺骗 SVN 认为更改已经被合并。它远没有 TFS 的实现那么优雅。您还不能像在 TFS 中那样获得简化的合并。
别忘了 Tortoise 让事情变得更容易，如果你想要从 'changesetB' 而不是 'changesetA' （其中变更集是 SVN 中的修订）的所有更改，那么您只需选择您想要的修订从 Tortoise 提供给你的日志中合并。

【解决方案3】：

我已经使用 subversion 很长时间了，让我告诉你，合并是可怕的，绝对是坏掉的。我已经更改为 mercurial，即使我对分布式的东西没有用处，只是为了获得有效的分支。

根据要求详细说明 要在 SVN 中成功合并，您需要 (ed) 知道分支所携带的版本号，只要您只进行一次合并回主干，这并不难找到。不幸的是，有时您需要多次合并（即事实证明，要添加一个您首先必须修复错误的功能）到主干，或者您正在不同分支之间进行合并，这使得无法跟踪哪个版本number 属于哪个分支，之前合并过的。

我使用的 SVN 版本是 1.5.1，所以它应该可以与新样式开发一起使用，虽然我错过了它。

【讨论】：

你指的是svn 1.5合并吗？
谢谢，您似乎指的是 1.5.5 之前的合并——从那以后，整个合并跟踪系统似乎得到了显着改进。我们在 Subversion 1.4 上进行了相当广泛的工作，并将其作为基线:-)

【解决方案4】：

有点离题，但是如果您的 Java 开发人员从 TFS 迁移的问题仍然悬而未决，我建议您看看 Teamprise。它是专为使用 TFS 的 Java 开发人员制作的工具。它为 Java 用户提供了 eclipse 中 Visual Studio 集成的大部分功能（有些功能甚至更好）。

http://www.teamprise.com/

（仅供参考，我与他们没有任何关系......）

瓦卡诺

【讨论】：

感谢您的提示，但我们已经评估了 Teamprise，发现它（当时）非常挑剔且不稳定。

【解决方案5】：

对于常见的情况，我认为 subversion 中的合并一点也不难，看看像 these 这样的例子。我发现合并非常简单易行；尽管一些同事抱怨更喜欢 CVS，其他人则抱怨 p4 等等等等。我怀疑这在很大程度上与熟悉其他工具有关，而不是与技术优势/劣势有关。

可能更复杂的（三路）合并更难，但问题是常用的合并是否是那些。就我个人而言，我认为复杂的合并（以及长期存在的分支、复杂的分支跟踪和合并策略等）是代码腐烂的味道（或者我猜是 SCM 腐烂）。 YMMV。

【讨论】：

【解决方案6】：

我不熟悉 TFS，但在 1.5 版之前，subversion 的合并支持仅包括获取（手动指定的）修订范围的差异，并将其应用于存储库中的另一个路径。在 1.5 版中，实现了合并跟踪，但它似乎是 rather complex 具有有趣的边缘情况。

如果合并对您很重要，您可能希望考虑一种擅长合并的 DVCS，例如 git 或 mercurial。

【讨论】：

并且需要注意的是，svn 1.5合并支持需要一段时间才能稳定。仅从 1.5.5 开始，它可以在几个实际案例中使用，我不记得 ATM，但这些案例在尝试在大型代码库（即 GCC）上采用 svn 1.5 支持时表现出色。
我们将使用 SVN 1.6.x 和一个相当简单的项目结构。 Git 和 Mercurial 对我们来说不是实用的选择；没有一个员工熟悉任何一个（或一般的 DVCS），我们无法承受由于范式转变而导致的（所谓的）生产力损失。
这个答案没有回答我的问题 - 它没有将 TFS 与颠覆进行比较。