Mercurial:Picking承诺包含在发布中

Question

我有一个本地的mercurial存储库(现在),我已经在其中进行了几次提交,每次提交都是一个自包含的bug修复.是否有可能在构建我的应用程序的发布版本时选择我想要包含哪些错误修复(提交).

详细说明,假设A,B,C,D和E是我已经对我的存储库做的提交,并且每个提交都涉及到如下的错误修复:

A <- B <- C <- D <- E <- working dir

我需要能够选择哪些错误修复将进入发布版本(这取决于为部署分配的时间以及测试结果).例如,我可能会收到一份报告,说该版本应该只包含错误修复A,C和D.

是否可以构建仅包含A,C和D提交的发布版本(请记住,每个提交都是自包含的,并且不依赖于实际存在的其他提交)？

可能为每个错误修复分配一个分支,然后合并到一个发布分支是最简单的方法来实现这个(或者不是吗？),但目前的情况如上所述,没有分支.

Answer 1

这不是Mercurial(或git)的正常工作模式.如果存储库还包含变更集的所有祖先,则它只能包含变更集.所以你不能在没有A,B和C的情况下将D放入回购.

所以这里是:

你应该做什么

控制变更集的父项.不要因为碰巧在C之后修复了D而使C成为D的父级.在将错误修复hg update到之前版本之前.

想象一下A是一个版本,B,C和D都是bug修复.如果你做这样的循环:

foreach bug you have:
    hg update A
    ... fix bug ...
    hg commit 
    hg merge  # merges with the "other" head

然后你会得到一个这样的图形:

---[A]----[B2]--[C2]--[D2]----
    |    /     /     /
    +-[B]     /     /
    |        /     /
    +-----[C]     /
    |            /
    +---------[D]

现在如果你想创建一个只包含B和D的版本,你可以这样做:

hg update B
hg merge D

并创造了一个有A + B + D但没有C的新头.

Tl;博士:让改变的父母尽可能早在历史上,而不是当时的任何提示.

你能做什么现在

这是理想的,但幸运的是,这不是什么大事.如果没有引入C,你就永远不会带来精确的 D(因为C的哈希是D'哈希计算的一部分),但是你可以很容易地将D中的工作带入一个新的脑袋.以下是一些方法,其中任何一个都可行:

• hg export/hg import
• hg移植
• hg移植(2.0中的新功能)
• hg rebase(只有在尚未推送的情况下才有可能)

任何这些都可以让你带来D中的补丁/增量 - 它会有一个不同的哈希ID,当有一天你将D合并为真实(使用合并)时,你将在两个不同的变更集中重复工作,但是合并将全力以赴.