我公司的产品是基于模块的，这意味着我们提供五个基本模块，用户可以购买额外的模块。我们使用的Mercurial是我们相对较新的源代码控制器，由于我们已经发布了1.0产品，因此管理单独的模块开发一直是个噩梦。
我们希望能够在不必等待特定模块开发完成的情况下发布小错误修正更新，因此所有内容的回购都不能很好地工作。我读到了分支，但权威指南似乎表明分支是暂时的，并且与之合并很困难。
理想情况下，我们有一个基础仓库是产品，然后是不同的回购（或分支）与额外的模块，因此QA可以分别构建主要产品和主要+插件，而开发人员在ModuleA上工作不要影响开发BugfixB的开发人员。我尝试了多个subrepos，但它最终破坏了我的存储库。
我应该考虑使用命名分支吗？还是书签？
我正在寻找关于如何利用Mercurial的功能来简化此过程的最佳实践建议。
谢谢！
答案 0 :(得分：6)
有一个关于http://nvie.com/git-model分支的好教程。 <重点是
还有一篇关于http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/
的mercurial分支技术差异的参考资料答案 1 :(得分：2)
分支是您的解决方案。我认为命名分支是一件好事。但是，您应该知道，命名分支需要一定程度的预见和使用纪律。
我建议每个bug-fix都有自己的分支。开发人员将分支该分支，执行错误修复，并合并回功能分支。
我会考虑将您的模块拆分为单独的存储库，每个产品一个。可能这不是很有用;你将不得不在那里查看不同的用例并确定工作流/编译流程的方式。
答案 2 :(得分：2)
我不明白为什么在整个文件历史记录几乎相同时你会考虑为此设置不同的subrepos - 这是分支机构的主要工作。唯一的复杂因素是能够为每个分支挑选补丁 - 这可能需要您导出补丁（或补丁集）并将它们单独应用于每个分支。它应该比它应该更尴尬，但它并不比在不同的存储库中做同样的事情更难。
答案 3 :(得分：1)
我认为这个问题模糊了两个不同的问题：
为了处理模块化产品，您应该为每个模块使用不同的存储库，并根据每个客户配置使用subrepos将它们组合在一起。看起来你已经这样做了，但是有腐败问题。这当然是正确的方法，因此您需要根据Mercurial错误或用户错误来判断损坏。
为了处理单独的开发周期，我个人会去模块克隆，但命名分支也没问题。
希望这有帮助。
答案 4 :(得分：0)
我也是Mercurial的新手，但我认为你的问题不是特定的。 您需要考虑释放代码和所涉及的各方的过程，并将此模型映射到可以支持它的分支布局。 Mercurial很好，因为它可以很好地支持开发人员，允许他们维护自己的开发“分支”，而不会影响连续构建或其他下游流程（QA，安装程序等）。
[Rel]
^
[RC]
^
[QA]----[QA]------[QA]
^ ^ ^
[开发] -------------------------------------------- -------------
^ ^ ^
[Jen] [Paul] [Ken]
这是一个可能的方案，开发人员合并到Dev，并且有人定期合并到[QA]分支，并且当它很好地进入[RC]等。 每个版本都与其他活动隔离。
祝你好运！