在Mercurial版本中管理流程工件-Java 学习之路

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

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

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

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

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

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

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

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

主要A - B - C - D - E - F - G - H - I - J - K - L --------- M ---- ---------ñ
\ / \ /
RC1 RC1.0 - RC1.1 \ /
\ / /
RC2 \ RC2.0 - RC2.1 - RC2.2
\
\
发布ER1.0 ----------------------------------- PR1.0

2 回答

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.0的错误修复版本（但没有新功能）的版本2.1，那么您继续使用相同的方案：
```
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 .
回复于 2024-04-29T23:02:11+08:00
0
你对mercurial的使用看起来有点复杂，所有这些合并到处都很难处理 . 您正在使用mercurial的分支功能，但似乎忽略了其他两个重要功能：
- 标签
- Cherry Pick
我将在下面描述我们对mercurial的一般用法，以突出这些功能：

Note that the following only applies to projects for which different versions need to be maintained over time.

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

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

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

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

This requires developers to push clean and atomic changesets, which is how things should be done in mercurial in the first place.

当您的提交在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并重新启动循环如上所述 .

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

如果不让我知道的话，我希望我很清楚 .
回复于 2024-04-29T23:02:11+08:00

在Mercurial版本中管理流程工件

2 回答

相关问题