评估源/版本控制工具的场景
我们目前正在研究不同的源代码控制工具，并希望使用一些轻量级但有意义的场景来测试每一种工具，以了解每一种工具的功能。
某些工具之间的术语和内部逻辑差异很大，最好用用例来表达场景（“我们必须纠正版本 1.3 上的错误”），而不是用潜在的工具来表达-特定术语（“创建名为 Release 1.3 的分支”）。
确实，不同的事情对于不同的团队来说很重要，但是拥有某种可以从中选择不同场景的规范测试用例会很有趣。还是我太乐观了？
有人知道这样的事情吗？您在研究源代码控制工具时是否使用过类似的方法？
We're currently researching different source control tools, and want to test each one with some light-weight but meaningful scenario to get a feel for the capabilities of each one.
Terminology and internal logic varying wildly between some tools, it would be nice to have the scenario expressed in terms of use cases ("We have to correct a bug on Release 1.3"), rather than in potentially tool-specific terms ("Create a branch named Release 1.3").
It's true that different things are important for different teams, but it would be interesting to have some kind of canonical test case from which different scenarios could be picked. Or am I being too optimistic?
Is anyone aware of something like this? Have you used a similar approach when investigating source control tools?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这些是 Mozilla 在 2006 年评估内部使用的版本控制系统时提出的要求。可能会发现类似的方法很有用。
如果您发现特定于您公司的场景，也许您可以将它们转化为上述要求。
These are the requirements that Mozilla had when they set out evaluate version control systems for internal use in 2006. You might find a similar approach useful.
If you find scenarios that are specific to your company, perhaps you can translate them to requirements like the ones above.
您对 Google DVCS 分析有一些一般标准，可以提供一些建议。
但您首先需要看看是否要评估：
要测试的不同场景的更多信息（CVCS 的一个答案， DVCS 的一个），请参阅 SO 问题：
“ 描述使用版本控制（VCS 或 DVCS）的工作流程 "
You have some general criteria with Google DVCS analysis which can give some ideas.
But you need first to see if you want to evaluate:
For more on the different scenario to test (one answer for CVCS, one for DVCS), see the SO question:
" Describe your workflow of using version control (VCS or DVCS) "
您必须提出以下问题：您是否只有一行发布/开发，或者我们是否并行创建多个版本？不仅需要提到的场景，您还需要考虑将更改合并回开发行或多个其他行的情况。这会影响方法。您选择的方法听起来非常好，因为您尝试理解该过程而不是使用工具术语。我已经为我的客户这样做过很多次了。在不同的团队/公司中，不同的事情处理方式不同。所以问题是弄清楚你的过程是什么（有时人们并没有意识到这一点）。
You have to question things like: Do you have only a single line of Release/Development or do we create multiple releases in parallel? No only the mentioned scenario is needed you need to think about upon that one like merging back the changes into dev line or multiple other lines as well. This can influence the approach. The approach you selected sounds very good cause you try to understand the process and not using tool terms. I've done that for multiple times for customers of mine. In different teams/companies different things are handled different. So the problem is to figure out what the process of yours is (sometime people are not aware of this).