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

Question

在我的办公室，我们正在从 Visual Source Safe（6.0！）过渡到 Mercurial，我正在尝试找出处理我们情况的最佳“Mercurial”方式。目前，在任何给定的项目存储库中，我们维护它的多个版本：即，对于项目 A，我们有一个用于 ProjA-Dev、ProjA-Rel1 和 ProjA-Rel2 的 VSS 存储库（一个开发存储库和一个用于过去两个发布）。

就目前而言，（几乎）所有新工作都在开发存储库中执行，然后手动完成被认为有必要回滚到 Rel1 或 Rel2 的更改（文件从 VSS 签出到自己的工作目录，然后使用一些差异工具仅复制适当的更改）。到了某个时候，认为有新版本出来了，所以克隆了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 存储库构建，所有活跃的开发都在这里进行，“aurora”从 mozilla-aurora 存储库构建，我们尝试在其中构建稳定发布代码，“beta”从mozilla-beta 存储库构建，我们在其中执行最终验证，并从mozilla-release 存储库发布构建。这些存储库中的每一个都作为单独的克隆进行维护。

The actual branch mechanics 从一个分支移动到另一个分支有点复杂。这些分支都有共同的历史，但由于 aurora 和 beta 分支在发布前夕移植了选定的安全性和稳定性修复程序，因此它们的历史不同。确切的过程记录在本段开头的链接中，但归结为：“标记 mozilla-central 存储库；标记并关闭 mozilla-aurora 的当前头；将 mozilla-central 推送到 mozilla-aurora 作为新头”。对 aurora->beta 重复相同的过程。

将开发中的修复程序向后移植到 aurora 或 beta 分支只是移植变更集的问题。如果您愿意，可以使用hg transplant 命令，我记录了我是如何做到的on my blog。

话虽如此，对于大多数项目来说，这可能是矫枉过正。我们使用单独的存储库克隆而不是命名分支，因为我们的命名分支工具不是很好，而且我们实际上更喜欢它给我们的隔离。您可以在此处将命名分支用于更轻量级的流程，只需在准备好时从默认分支创建一个新的命名分支，然后在默认情况下继续开发时根据需要向后移植修复。