1

在我的办公室，我们正在从 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 的区别最好由不同的命名分支处理。但是，我无法弄清楚/看到/环绕的是如何在这样的环境下完成我们当前的工作流程。如果我们遵循我们当前的工作流程，那么 dev-branch 中的工作将继续有增无减，并且某些更改（不是全部！）将回滚/回滚到 Rel 分支。我知道这可以通过 Mercurial 的移植/移植功能来实现，而 TortoiseHg 似乎还没有很好地支持它。而且，更重要的是，过去的答案似乎表明，最好的解决方案是不允许事情以1开始进入这种状态。

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

4

1 回答 1

6

我不知道这是否完全适合您，但我可以为您提供一些有关Mozilla 如何使用 Mercurial的信息。我们每六周发布一次 Firefox，我们有几个并行运行的不同分支：“夜间”从mozilla-central存储库构建，所有活跃的开发都在这里进行，“aurora”从mozilla-aurora存储库构建，我们尝试在其中构建稳定发布代码，“beta”从我们执行最终验证的mozilla-beta存储库构建，并从mozilla-release存储库发布构建。这些存储库中的每一个都作为单独的克隆进行维护。

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

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

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

于 2012-08-28T13:55:53.213 回答