svn - 如何在不同的源代码控制系统下开发 merge 文件的陷阱测试和性能测试？

Question

在我工作的地方，我们多年来一直在使用 Subversion(显然，我来这里的时间并不长)。这里有些人更喜欢使用 TFS，有些人更喜欢迁移到 Mercurial，有些人更喜欢保持现状。由于 Visual Studio 集成不佳，其他源代码控制(Git 等)无法运行。

新的源代码控制会减弱的最大问题/恐惧是对分支/merge 的恐惧。

我想构建一个测试，直接说明哪个源代码管理更擅长 merge 两个分支。考虑到可能没有 TFS 的“演示”版本，这可能很困难。不过，这似乎是一个有趣的问题。

要对此进行测试，我需要了解以下内容:

• merge 算法通常不擅长什么？
• 我能否找到有关源代码控制系统(特别是 TFS)使用何种 merge 算法的信息？
• 我能想出一种 merge 算法相对于另一种算法的优势吗？
• 大多数 VCS 在处理哪些类型的文件时遇到问题？

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

Answer 1

关于TFS，你有一个小Branching and Merging Primer ，这可能没有考虑到 branches became first-class citizen with TFS2010 .

您可以在此 Merging: hg/git vs. svn 中看到有问题的 merge 问题(最初关于 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 不会 merge 二进制元素(除了一些像 word 文档)。