评估源代码/版本控制工具的方案

Question

我们目前正在研究不同的源代码管理工具，并希望用一些重量轻但有意义的场景来测试每个工具，以了解每个工具的功能。

术语和内部逻辑在某些工具之间差别很大，最好用用例(“我们必须更正1.3版的错误”)来表达场景，而不是用特定于工具的术语(“创建一个名为Release1.3的分支”)。

的确，对于不同的团队来说，不同的事情是很重要的，但是有某种规范的测试用例可以从中选择不同的场景是很有趣的。还是我太乐观了？

有人知道这种事吗？在调查源代码管理工具时，您是否使用过类似的方法？

Answer 1

这些都是Mozilla的要求，当他们在2006年提出评估版本控制系统供内部使用时。您可能会发现类似的方法很有用。

如果您发现特定于您的公司的场景，也许您可以将它们转换为类似于上面的需求。

Answer 2

您有一些关于Google分析的通用标准，它可以给出一些想法。

但你需要先看看你是否想评估：

• 中央版本控制:更新-合并-提交
• 分布式版本控制:提交-重基/合并

有关要测试的不同场景的更多信息( CVCS的一个答案，DVCS的一个)，请参见SO问题：

“描述使用版本控制(VCS或DVCS)的工作流程。”

Answer 3

您必须对这样的问题提出疑问:您是只有一个版本/开发，还是我们并行地创建多个版本？不需要只考虑上述场景，您需要考虑的是这个场景，比如将更改合并回dev行或多个其他行。这可能会影响这一方法。您选择的方法听起来非常好，因为您试图理解流程，而不是使用工具术语。我已经为我的顾客做过好几次了。在不同的团队/公司中，不同的事情被不同的处理。所以问题是弄清楚你的过程是什么(有时人们不知道这一点)。