如何在不同的源控制系统下开发合并文件的陷阱测试和性能测试？

Question

在我工作的地方，我们多年来一直在使用Subversion（显然，我已经很久没在这里了）。这里有些人更喜欢使用TFS，有些人更愿意迁移到Mercurial，有些人更愿意保持现状。其他源代码控件（Git，其他）因Visual Studio集成不佳而无法启动。

新的源控件会减弱的最大问题/担心是对分支/合并的恐惧。

我想构建一个测试，直接解决哪个源代码控制更好地合并两个分支。考虑到可能没有TFS的“演示”版本，可能很难。不过，这似乎是一个有趣的问题。

为了测试这个，我需要知道以下内容：

• 什么是合并算法通常不好？
• 我可以找到源控制系统使用的合并算法（特别是TFS）的信息吗？
• 我可以想出一个合并算法会比另一个更好的优势吗？
• 大多数VCS遇到什么类型的文件？

更重要的是，你们中有谁知道有人已经这样做了吗？

Answer 1

关于TFS，你有一个小的Branching and Merging Primer，可能不会考虑branches became first-class citizen with TFS2010的事实。

您可以在此Merging: hg/git vs. svn问题中看到有问题的合并（最初关于Git，但可以推广到其他VCS）：任何类型的 criss-cross merging 通常都难以处理正常。

从那里，你也可以参考：

• What makes some version control systems better at merging?
• Why is branching and merging easier in Mercurial than in Subversion?

大多数VCS不会合并二进制元素（有些像word文档除外）。

Answer 2

我不确定您是否会在不同工具的性能测试中找到很多用途。关于可解析的合并，所有工具都很快。问题和比较点是它们经常导致冲突的频率。 2008年TFS和之前的会议在解决冲突方面非常糟糕。 2010与我使用的任何其他系统相同，包括Git。你可能会在那里找到ney-sayers，但是他们正在考虑2008年（不可否认你在解决合并方面非常糟糕）。

关键是经常推或拉。如果分支，请确保经常从父分支拉出。离开的时间越长，冲突的可能性就越大。对于生成的文件（例如resx文件和.xxproj文件）尤其如此。