在我的办公室，我们正在从Visual Source Safe（6.0！）过渡到Mercurial，我正在努力寻找处理我们情况的最佳“Mercurial”方式。目前，在任何给定的项目存储库中，我们维护它的多个版本：即对于项目A，我们有一个VSS Repo for ProjA-Dev，ProjA-Rel1和ProjA-Rel2（dev repo和过去两个中的每一个）版本）。
现在，（几乎）所有新工作都在dev repo中执行，然后被认为必须回滚到Rel1或Rel2的更改是手动完成的（从VSS检出的文件到他们自己的工作目录，然后使用一些diff工具只复制相应的更改）。在某些时候，它被认为是一个新的版本，所以dev repo被克隆，它变成了Proj * -Rev1，之前的Proj * -Rev1变成了Proj * -Rev2，而Proj * -Dev只是继续好像什么也没发生过。在我看来，必须有一个更好的方法来实现这个更现代的工具，如Mercurial。
我目前的想法是每个项目都应该有自己的存储库，Dev / Rel1 / Rel2的区别最好由不同的命名分支处理。然而，我无法弄清楚/看到/包裹我的头脑是如何在这样的环境下完成我们当前的工作流程。如果我们遵循当前的工作流程，那么dev-branch中的工作将继续有效，并且某些更改（不是全部！）将回滚到Rel分支。我知道这可以通过Mercurial的移植/移植功能来实现，这在TortoiseHg中似乎还没有得到很好的支持。而且，更重要的是，过去的答案似乎表明，对此最好的解决方案是不允许事情以1开始进入这种状态。
问题是，考虑到当前的工作流程，避免这种状态的最佳方法是什么？我已经阅读了很多关于Mercurial和分支的指南（包括很多很多，在这里找到的回复）但是没有看到这个问题的明确答案。
答案 0 :(得分：6)
我不知道这是否适合您，但我可以提供一些有关how Mozilla uses Mercurial的信息。我们每六周发布一次Firefox，并且我们有几个并行运行的不同分支：来自mozilla-central存储库的“nightly”构建，其中所有活动开发都发生，“aurora”构建自mozilla-aurora存储库，在我们尝试稳定发布代码的地方，“beta”构建自mozilla-beta存储库，我们在其中执行最终验证，并从mozilla-release存储库发布构建。这些存储库中的每一个都作为单独的克隆进行维护。
从一个分支移动到另一个分支的The actual branch mechanics有点复杂。所有分支都有共同的历史记录，但由于极光和beta分支在预先发布的过程中被选中的安全性和稳定性修复移植到它们，因此它们具有不同的历史。确切的过程记录在本段开头的链接中，但它归结为：“标记mozilla-central存储库;标记并关闭当前的mozilla-aurora头;将mozilla-central推向mozilla-aurora作为新头“。对于极光 - >β重复相同的过程。
从开发到极光或beta分支的向后移植修复只是移植变更集的问题。如果您愿意，可以使用hg transplant命令，我记录了我是如何做到的on my blog。
所有这一切，对于大多数项目而言，这可能是过度的。我们使用单独的存储库克隆而不是命名分支，因为我们对命名分支的工具不是很好，我们实际上更喜欢它给我们的隔离。您可以在这里使用命名分支来实现更轻量级的进程，只需在准备就绪时从默认分支创建一个新的命名分支，并在默认情况下继续开发时根据需要进行后端修复。