svn - Subversion 中的合并是否比 Team Foundation System 中的合并更困难？

Question

我习惯使用 TFS，我的公司现在正在为一个新项目切换到 SVN(主要原因是为了更好地将我们的 java 和 .Net 代码库合并到同一源代码管理下)。
我了解到 subversion 中的合并很难(Jeff mentioned this 在他最新的播客中)。

与 TFS 相比，subversion 有哪些问题？

如何缓解？ (在颠覆的范围内，或者按照杰夫的建议，选择另一个源代码控制)

TFS 提供的一项强大功能是它的自动合并功能(在 TFS2008 中得到了很大改进，虽然还不完美)。大多数合并不需要用户的任何操作。这在颠覆中是一样的吗？
更新 - 此处接受的答案只能来自在 中都经历过大规模合并的人TFS 和 颠覆 ，并且实际上可以比较和对比两者。知道“在颠覆中合并是好的”或“TFS 是垃圾”并不能真正帮助我做出决定，因为它是主观的。如果您可以与其他替代方案进行比较，那就太好了 - 这很有帮助。但我的重点是颠覆与 TFS。
我感兴趣的目标团队规模是 6-30 名活跃的开发人员。
更新 2 - 有没有人会说在 SVN 中合并实际上比在 TFS 中更容易(考虑到工具)？

Answer 1

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

您已经熟悉 TFS，所以我会为您提供详细信息，而不是说 changesets和 TFS 工具使这个过程变得非常简单。由于取消删除问题，我们确实收到了 TF14087 错误，但很快就解决了。

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

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