testing - 使用 Mercurial 时，在内部发布产品测试版本并保留 "what is in this version"列表的过程？

Question

为此我需要一些具体的想法。

我们正在考虑改变我们的版本控制系统，我希望我们使用 Mercurial。它将减轻与某些内部流程相关的许多痛苦，并带来一些挑战。

其中一个挑战是我们目前使用的版本控制系统不是分布式系统，因此具有我们在内部使用的每个变更集的修订号概念。

基本上，当程序员在我们的案例管理系统中 checkin 修复案例的最终更改时，Visual Studio 会响应这变成了哪个变更集编号，然后程序员将其附加到案例上，基本上说“如果你是运行我们产品的最新版本号为这个值或更高的版本，那么您将拥有该版本中的所有更改。”

但是，对于 Mercurial，这不起作用，因为修订号可以并且将会随着来自不同分支的提交而改变。

所以我想知道如何获得类似的东西。

请注意，这与发布管理无关。发布受到更多控制，但正在进行的测试更加流畅，因此我们希望避免让测试人员不断尝试弄清楚他列表中的测试用例是否真的适用于他正在测试的版本。

基本上，我需要测试人员能够查看他们正在测试的版本是否具有与测试用例相关的更改。

我正在考虑以下内容:

1. 程序员提交并获取变更集的哈希值
2. 程序员将此附加到我们的案例跟踪器中的案例
3. 构建过程必须标记(不是以 Mercurial 方式)版本，以便它知道它是从哪个变更集构建的
4. 我必须轻松地获取构建我们产品的变更集的哈希值，在用于构建机器的存储库的变更集日志中查找它，然后确定产品变更集是否是与测试列表中的每个案例相同或它们的祖先。

所以我有两个问题:

1. 这是可行的方法吗？我并不反对创建一个让这一切变得容易处理的网络应用程序
2. 有人知道可以帮助我的替代过程吗？我看过标记，但似乎标记最终会增加 merge 压力，这是我想要的吗？ (即添加/移动标签最终作为提交，需要与系统的其余部分 merge )
3. 有没有什么东西可以帮助我开箱即用，也就是说，有人已经制作或知道这样的东西吗？
4. 还有其他想法吗？

Answer 1

您正在寻找与您的构建过程相关联的轻量级标记过程是否正确？

我不喜欢程序员获取最后一个散列并将其粘贴到其他地方的想法 - 听起来像是您不能依赖的手动过程。您能否围绕程序员将案例编号添加到他们的提交消息来构建一个流程，以便某物稍后可以将提交链接到原始案例？当案例被标记为“已关闭”时，您可以选择针对该案例的所有提交。

很多案例控制系统都有这个 - Fogbugz ，例如。