我公司的产品是基于模块的，这意味着我们附带五个基本模块，用户可以购买额外的模块。我们使用相对较新的 Mercurial 来进行源代码控制，自从我们发布了产品 1.0 以来，管理单独的模块开发一直是一场噩梦。
我们希望能够发布较小的错误修复更新，而不必等待特定模块开发完成，因此一个存储库可以解决所有问题并不能很好地工作。我读过有关分支的内容，但《权威指南》似乎表明分支是暂时的，并且与其合并很困难。
理想情况下，我们有一个基础存储库，即产品，然后是带有额外模块的不同存储库（或分支），以便 QA 可以分别构建主产品和主+插件，而从事 ModuleA 的开发人员则不需要影响致力于 BugfixB 的开发人员。我尝试了多个子存储库，但最终损坏了我的存储库。
我应该考虑使用命名分支吗？还是书签？
我正在寻找有关如何利用 Mercurial 的功能来简化此过程的最佳实践的建议。
谢谢！
My company's product is module-based, meaning we ship with five base modules and users can purchase additional ones. We're using Mercurial, to which we are relatively new, for our source control, and since we've released 1.0 of our product, managing the separate module development has been a nightmare.
We want to be able to release minor bugfix updates without having to wait for particular module development to be complete, so one repo for everything doesn't work very well. I read about branching but the Definitive Guide seems to suggest that branching is temporary, and that merging with it is difficult.
Ideally, we'd have a base repo that is the product and then different repos (or branches) with the extra modules, so that QA could build the main product and the main+addons separately, while the developers working on ModuleA don't impact the developers working on BugfixB. I tried this with multiple subrepos but it ended up corrupting my repositories.
Should I be looking at using named branches? Or bookmarks?
I'm looking for suggestions on best practices on how we can take advantage of Mercurial's features to make this process easier.
Thanks!
发布评论
评论（5）
我也是 Mercurial 的新手，但我认为您的问题并不是专门针对它的。
你需要考虑发布代码的过程和涉及的各方，并将这个模型映射到可以支持它的分支布局。
Mercurial 很好，因为它可以很好地支持开发人员，允许他们维护自己的开发“分支”，而不影响持续构建或其他下游流程（QA、安装程序等）。
[开发]-------------------------------------------------------- ----------
这是一个可能的方案，开发人员合并到 Dev，有人定期合并到 [QA] 分支，当它成熟时转到 [RC] 等。
每个版本都与其他活动隔离。
祝你好运！
I am new to Mercurial as well, but I think that your problem is not specific to it.
You need to think about the process of releasing code and the parties involved, and map this model to a branch layout that can support it.
Mercurial is nice because it can support developers well, by allowing them to maintain their own development "branches" without affecting a continuous build or other downstream processes (QA, installers, etc).
[Dev]---------------------------------------------------------
this is a possible scheme, where developers merge to Dev, and somebody merges regularly to the [QA] branch, and when that it baked nice goes to [RC] etc.
Every release stays isolated from other activity.
Good Luck!
http://nvie.com/git-model 有一个关于分支的很好的教程。要点是拥有
此外，还有关于 Mercurial 分支的技术差异的参考 http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/
There is a good tutorial about branching at http://nvie.com/git-model. The main point is to have
Also there is a reference about the technical differences in mercurial branches at http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/
分支是您的解决方案。我认为命名分支是一件好事。但是，您应该意识到命名分支在使用时需要一定程度的深思熟虑和纪律。
我建议每个错误修复都有自己的分支。开发人员将分叉该分支，修复错误，然后合并回功能分支。
我会考虑将您的模块分成单独的存储库，每个产品一个。可能这不是很有用；您必须在那里查看不同的用例并确定工作流程/编译流程将如何进行。
Branching is your solution. I consider named branches to be a Good Thing. However, you should be aware that named branches require a certain level of forethought and discipline in use.
I would suggest that each bug-fix gets its own branch. Developers will fork off that branch, do the bugfix, merge back into the feature-branch.
I would consider splitting your modules into separate repositories, one for each product. Possibly that's not very useful; you'll have to go over different use cases there and determine how the workflow/compile-flow would go.
当文件历史记录几乎相同时，我不明白为什么您会考虑为此使用不同的子存储库 - 这是分支的主要工作。唯一的复杂之处是能够为每个分支挑选补丁 - 这可能需要您导出一个补丁（或一组补丁）并将它们单独应用到每个分支。这比应有的情况要尴尬一些，但这并不比在不同的存储库中执行相同的操作更难。
I don't see why you'd consider having different subrepos for this when the file history is virtually the same throughout - this is a prime job for branches. The only complication is being able to cherry-pick patches for each branch - that may require you to export a patch (or set of patches) and apply them individually to each branch. It's a bit more awkward than it should be, but it's no harder than doing the same across different repositories.
我认为这个问题模糊了两个不同的问题：
为了处理模块化产品，您应该为每个模块使用不同的存储库，并使用 子存储库 适用于每个客户配置。您似乎已经在这样做，但遇到了腐败问题。这当然是正确的方法，因此您需要弄清楚损坏是否来自 Mercurial 错误或用户错误。
为了处理单独的开发周期，我个人会选择模块克隆，但命名分支也可以。
希望这有帮助。
I think the question blurs two different issues:
For handling the modular product you should use different repositories for each module and bring them together using subrepos as appropriate for each customer configuration. It appears you're already doing this but are having corruption issues. This is certainly the correct way to go so you need to bottom-out whether the corruption is coming from a Mercurial bug or user error.
For handling separate development cycles then personally I'd go for module clones but named branches would also be fine.
Hope this helps.