Question

我想知道使用Mercurial创建包含提供流程执行证据的工件的版本修订版的最佳方法是什么。例如，我们想附加系统测试结果，检查清单，发布说明等，这样如果我们经过客户审核，我们就可以轻松地显示我们已经完成了我们的流程。由于我们产品的安全性，这对我们很重要。

我们的发布管理流程将如下图所示。所有开发人员都在开发本地回购并定期推向主要。 Main是最新且最好的，但对于开发团队以外的内部工程目的来说不一定安全。

当我们想要为客户或其他内部工程部门创建发布时，我们从发布候选分支（例如RC1）开始。如果需要任何修复，我们将提交RC分支。测试发生在这个分支上。当RC被确定为好时，更改将合并回main。

我们认为我们想要做的是合并到Releases分支。但是，我们有一个与工件相关的鸡和蛋问题：我们希望在发布版本中包含的工件包含修订的哈希等。这提供了明确的可追溯性，即对此精确修订执行了测试和其他处理步骤。但是，要添加这些项目，我需要创建一个新的修订版本，在创建之前我显然无法知道该修订版本的哈希值。我想知道是否有某种方法可以在不改变哈希的情况下“修改”修订版？

我能想到的唯一方法就是，例如，在下图中，创建一个包含必要的流程工件但实际上将RC2.2合并到Releases的修订RC2.3。 / p>

然后，当然，我有另一个问题，那就是将RC2.2合并到Releases会产生一个新的哈希。所以，我的文物再次过时了。所以下一个问题是是否有某种方法让Release分支“指向”RC2.2。

顺便说一下，如果有必要，我们愿意改变这个过程。我们使用这种方法的原因是：

CI系统正在监控主系统并启动一系列构建，并在每次推送时执行自动单元测试。主要频繁更改，我们不希望有人使用它。
开发可以继续进行，对发布没有任何影响。
Releases分支上的任何修订都会在CI平台上启动一组不同的任务，包括创建现场闪存实用程序的分发和所需的映像（我们正在开发固件）。这就是我们向外部实体提供发布的方式。

Main         A--B--C--D--E--F--G--H--I--J--K--L---------M-------------N  
                       \            /          \                     /  
RC1                     RC1.0--RC1.1            \                   /  
                         \                       \                 /  
RC2                       \                        RC2.0--RC2.1--RC2.2  
                           \                                       \   
                            \                                       \  
Releases                    ER1.0-----------------------------------PR1.0

Answer 1

回答你的问题：

我想知道是否有某种方法可以“修改”修订版而不更改哈希值？

不，这在设计上是不可能的。变更集散列是从提交内容派生的加密校验和 - 这就是变更集散列唯一标识变更集中所有文件的内容的原因。

Mercurial wiki有一个standard branch setup页面。我将描述它如何与下面的图片一起使用。

在您的情况下，人们通常会为您建议的候选版本创建分支。如果您即将发布固件版本2.0，那么我会调用分支2.x。分支上的提交是版本2.0的候选版本：

Main      A--B--C--D--E--F--G--H--I--J--K--L---------M-------------N  
                 \                /
2.x               2.0-RC1--2.0-RC2

根据需要在分支上提交错误修正，并定期合并回Main。你应该总是能够将错误修正合并回来，因为它们是因为它们的性质错误修正和你想要在Main上的稳定性改进。换句话说，上面的提交I包含2.0-RC2中的错误修正以及D到H中的新功能。

您可以根据需要在发布候选分支上工作并继续修复错误：

Main      A--B--C--D--E--F--G--H--I--J--K--L-------M-------------N  
                 \            /                   /
2.x               2.0-RC1--2.0RC2 -- ... --2.0-RC8

所有错误修正都被合并回来，因为规则是你只能对发布候选分支进行安全修复。在这里，您在发布分支上有8个候选版本。

如果您喜欢候选版本的状态，可以对其进行标记并对标记的修订版本运行更全面的测试。成功测试的输出在分支上提交，然后您将提交标记为最终发布的版本：

Main      A--B--C--D--E--F--G--H--I--J--K--L-------M-----------N  
                 \            /                   /           /
2.x               2.0-RC1--2.0RC2 -- ... --2.0-RC8 -- T -- 2.0

此处T包含2.0-RC8的测试输出。提交T是您标记为软件版本2.0以及您打包并发送给客户的版本。

如果你需要创建一个版本2.1，其错误修正为2.0（但没有新功能），那么你继续使用相同的方案：

Main      A--B--C--D--E--F--G--H--I--J--K--L-------M-----------N  
                 \            /                   /           /
2.x               2.0-RC1--2.0RC2 -- ... --2.0-RC8 -- T -- 2.0 -- 2.1-RC1

这就是为什么我打电话给分支2.x。

Answer 2

你对mercurial的使用看起来有点复杂，所有这些合并到处都很难处理。您正在使用mercurial的分支功能，但似乎忽略了其他两个重要功能：

标签
Cherry Pick

我将在下面描述我们对mercurial的一般用法，以强调这些功能：

请注意，以下内容仅适用于需要不断维护不同版本的项目。

主分支（在mercurial中称为默认分支）专门用于当前应用程序的开发。每当开发人员完成功能的开发/修改/更新时，他/她就会将他们的更改推送到默认状态，然后可供所有人和我们的CI（jenkins）使用，这将确保没有任何内容被破坏。

当我们到达即将发布新版本的阶段时，会创建一个分支。在引用您的架构时，分支可以命名为MY_PRODUCT_1_0

开发人员将继续使用默认分支，并且每当提交需要在即将发布的版本中时，相关的变更集将通过命令hg graft REV_CHANGESET（cherry pick）复制到MY_PRODUCT_1_0分支（注意）您也可以从MY_PRODUCT_1_0分支复制到默认值。

因此，您基本上选择默认分支中的哪些变更集将使其成为当前版本，而无需合并2个分支。

这需要开发人员推出干净的和原子的变更集，这就是首先应该在mercurial中完成的事情。

当你的提交在MY_PRODUCT_1_0中发展时，你可以在MY_PRODUCT_1_0_RC_1，MY_PRODUCT_1_0_RC_2，...的模式中多次标记它... 当在此分支上创建最终变更集时，您只需将其标记为MY_PRODUCT_1_0_PR_1_0

然后，您首先只获得2个分支，默认（开发分支）和MY_PRODUCT_1_0（您的第一个版本），随着时间的推移，当您需要发布产品的新版本时，您将创建一个新的分支MY_PRODUCT_2_0和如上所述重新启动循环。

使用这种方法，您确信您只在发布版本中进行了必要的更改，而不是在合并分支时获得的额外更改。

我希望我明白，如果不让我知道的话。

在Mercurial版本中管理流程工件

2 个答案: