如何使用Mercurial管理产品的多个版本?

有一个关于分支的好教程 http://nvie.com/git-model

• 只包含来自已完成的发布/错误修复分支的合并的发布分支
• 缺陷修复或特性的开发分支

此外,还有一个关于汞分支技术差异的参考 http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

分支是你的解决方案。我认为命名分支是件好事。但是,您应该知道,命名的分支在使用时需要一定程度的预先考虑和规范。

我建议每个bug修复都有自己的分支。开发人员将分叉该分支,进行错误修复,并合并回feature分支。

我会考虑将您的模块拆分为单独的存储库,每个产品对应一个存储库。可能这不是很有用;您必须检查不同的用例,并确定工作流/编译流将如何进行。

我不明白为什么在文件历史记录几乎完全相同的情况下,您会考虑使用不同的子回购—这是分支的主要工作。唯一复杂的是能够为每个分支挑选补丁-这可能需要导出一个补丁(或一组补丁)并将它们分别应用于每个分支。这有点尴尬,但并不比在不同的存储库中执行相同的操作困难。

我认为这个问题模糊了两个不同的问题:

1. 你有一个模块化的产品
2. 每个模块都有单独的开发周期

为了处理模块化产品,您应该为每个模块使用不同的存储库,并使用 subrepos 适用于每个客户配置。看起来你已经在这么做了,但是有腐败问题。这当然是正确的方法,所以您需要弄清损坏是来自于一个反复无常的bug还是用户错误。

对于处理单独的开发周期,我个人会选择模块克隆,但命名分支也可以。

希望这有帮助。

我对Mercurial也很陌生,但我认为你的问题并不是它特有的。 您需要考虑发布代码的过程和涉及的各方,并将此模型映射到能够支持它的分支布局。

                            [Rel]

                               ^

                             [RC]
                               ^

            [QA]----[QA]------[QA]
              ^       ^        ^

[开发人员]---------------------------------------------------------

       ^          ^          ^
      [Jen]      [Paul]    [Ken]

这是一个可能的方案,开发人员合并到Dev,有人定期合并到[QA]分支,然后它会转到[RC]等。 每次释放都与其他活动保持隔离。