维护开发/发布分支​​的Mercurial最佳实践？

Question

在我的办公室，我们正在从Visual Source Safe（6.0！）过渡到Mercurial，并且我正在设法处理我们处境的最佳“Mercurial”方式。目前，在任何给定的项目存储库中，我们都维护了它的多个版本：即对于项目A，我们有ProjA-Dev，ProjA-Rel1和ProjA-Rel2的VSS回购（一个dev回购和过去两年版本）。现在看来，几乎所有新工作都在dev回购中进行，那么被认为需要回滚到Rel1或Rel2的更改是手动完成的（文件从VSS签出到他们的自己的工作目录，然后使用一些diff工具只复制适当的更改）。在某些时候，它被认为会发布一个新版本，所以dev repo被克隆，并且它变成了Proj * -Rev1，并且之前的Proj * -Rev1变成了Proj * -Rev2，并且Proj * -Dev只是继续仿佛什么也没有发生。在我看来，必须有更好的方式来完成这个更现代的工具，如Mercurial。

我目前的想法是，每个项目应该有自己的存储库，Dev/Rel1/Rel2的区别最好由不同的命名分支来处理。然而，我无法弄清楚/看到/包裹我的头是如何在这样的环境下完成我们当前的工作流程。如果我们遵循我们当前的工作流程，那么开发分支中的工作仍会继续下去，并且某些更改（并非全部！）会回滚到Rel分支。我知道这可以通过Mercurial的移植/移植功能来完成，但它似乎还没有在TortoiseHg中得到很好的支持。而且，更重要的是，过去的回答似乎表明，最好的解决办法是不让事情进入这种状态，以1开头。

问题是，鉴于当前工作流程，避免这种状态的最佳方法是什么？我已经阅读了许多有关Mercurial和分支的指南（包括许多在这里找到的答案），但没有看到这个问题的明确答案。

Answer 1

我不知道这是否适合你，但我可以给你一些关于how Mozilla uses Mercurial的信息。我们每六周发布一次Firefox，并且我们有几个不同的分支并行运行：“夜间”从mozilla-central存储库构建，所有活动的开发都在这里进行，“极光”来自mozilla-aurora存储库，我们试图稳定代码发布，“测试版”从mozilla-beta存储库构建，我们在那里执行最终验证，并从mozilla-release存储库发布构建版本。每个存储库都作为独立的克隆来维护。

The actual branch mechanics从一个分支移动到另一个分支有些复杂。这些分支都具有共同的历史，但是由于极光和测试版分支在发布之前将选定的安全性和稳定性修正移植到它们中，所以它们具有不同的历史。确切的过程记录在本段开头的链接中，但归结为：“标记mozilla中央存储库;标记并关闭当前的mozilla-aurora头部;将mozilla-central归为mozilla-aurora作为新头“。对于极光 - >测试，重复相同的过程。

从开发到极光或测试版分支的反向修复只是移植变更集的问题。如果你愿意，你可以使用hg transplant命令，我记录了我如何做到这一点。on my blog。

所有这些说法，这可能是对大多数项目来说矫枉过正。我们使用单独的存储库克隆而不是命名分支，因为我们对命名分支的工具不是很好，我们实际上更喜欢它给我们的隔离。您可以在这里使用命名分支进行轻量级进程，只需在准备就绪时从默认分支创建新的命名分支，并在开发继续默认情况下根据需要进行修复。