我习惯使用TFS，我的公司现在正在转换到新项目的SVN（主要原因是在同一源代码控制下更好地整合我们的java＆amp; .Net代码库）。
我了解颠覆中的合并很难（Jeff mentioned this在他的最新播客中）。
TFS提供的一个强大功能是其自动充电功能（在TFS2008中有很大改进，虽然还不完美）。大多数合并不需要用户执行任何操作。在颠覆中是一样的吗？
更新 - 此处接受的答案只能来自在 TFS 和颠覆中经历过大合并的人，并且可以实际比较＆安培;对比两者。知道“颠覆合并是好的”或“TFS是垃圾”并不能真正帮助我做出决定，因为它是主题。如果你可以与其他替代方案进行比较，那就太棒了 - 这很有用。但我的重点是颠覆与TFS。
我感兴趣的目标团队规模是6-30名活跃的开发人员。
更新2 - 是否有人认为SVN合并的情况实际上比TFS更容易（考虑工具）？
答案 0 :(得分：6)
我在TFS和Subversion中都进行了大合并。 TFS代码库是SharePoint应用程序的1.5-> 2.0分支，生产更改合并到2.0代码库中。 SVN合并是将fork中的新功能合并到基线源中。
您已经熟悉TFS，所以除了说changesets和TFS工具使这个过程变得非常简单之外，我将为您提供详细信息。由于取消删除问题，我们确实收到了TF14087错误，但很快就解决了。
在SVN中，这个过程非常简单，因为我们不得不在SVN中定位文件的特定版本，而SVN对文件进行了扩展，这些文件不允许我们在TFS中使用变更集的灵活性（例如as“并非ChangesetA中的所有更改，但ChangesetB中的所有更改”）。我们当时没有合并跟踪，我们的源代码树也不是为了支持SVN合并跟踪的最佳实践。
我认为，现在，通过SVN中的合并跟踪，假设您遵循CollabNet概述的最佳实践，该过程将会更加简单。但请记住，TFS是一个很棒的产品，有很好的GUI工具来管理你的源代码，而SVN更多地依赖于命令行，所以如果你习惯使用GUI，这会让事情变得复杂。
答案 1 :(得分：5)
我不认为颠覆中的合并对于常见情况来说都很难，看看像these这样的例子。我发现合并简单易行;虽然有些同事抱怨更喜欢CVS，其他人抱怨等等。我怀疑其中很多都与熟悉其他工具有关，而与技术优势/劣势无关。
可能更复杂（三向）的合并更难，但问题是那些常用的是那些。我个人认为复杂的合并（和长寿命的分支，复杂的分支跟踪和合并策略等）代码腐烂的气味（或者我猜SCM腐烂）。 YMMV。
答案 2 :(得分：4)
我不熟悉TFS，但在版本1.5之前，subversion的合并支持仅仅包括（手动指定的）修订版本的差异，并将其应用于存储库中的另一个路径。在版本1.5中，实现了合并跟踪，但它似乎是rather complex有趣的边缘情况。
答案 3 :(得分：3)
我已经使用了很长一段时间的颠覆，让我告诉你，合并是可怕的，绝对是破碎的。我已经改为mercurial，即使我没有使用分布式的东西，只是为了让分支有效。
按要求详细说明 要在SVN中成功合并，您需要（ed）知道分支所携带的版本号，只要您只进行一次合并回主干，就不难找到。不幸的是，有时你需要多次合并（即，事实证明，首先要添加一个你必须修复bug的功能）到主干，或者你正在不同的分支之间进行合并，这使得无法跟踪哪个版本number属于哪个分支以及之前已合并的内容。
我使用的SVN版本是1.5.1，所以它应该适用于新的样式开发，虽然看起来我错过了。
答案 4 :(得分：0)
有点偏离主题，但如果从你的Java开发人员的TFS转移的问题仍然悬而未决，我建议你看看Teamprise。它是专为使用TFS的Java开发人员而设计的工具。它为Eclipse用户提供了eclipse中大部分Visual Studio集成功能（有些甚至更好）。
（仅供参考，我不以任何方式与他们有任何关系......）
Vaccano
答案 5 :(得分：0)
所有系统都有利弊。
但是一个有用的注释（接近主题）是一个外部强大的merge / diff程序通常非常有用。 因此，无论您选择什么，请确保您有一个很好的3向合并工具，以帮助自动化的东西中断。
BR 约翰