Mat*_*ord 1 mercurial branch tortoisehg
在我的办公室,我们正在从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和分支的指南(包括很多很多,在这里找到的回复)但是没有看到这个问题的明确答案.
我不知道这是否适合你,但我可以给你一些关于Mozilla如何使用Mercurial的信息.我们每六周发布一次Firefox,并且我们有几个不同的分支并行运行:mozilla-central存储库中的"nightly"构建,所有活动开发都发生,"aurora"构建自mozilla-aurora存储库,我们尝试在稳定发布代码,从mozilla-beta存储库构建"beta"版本,我们在其中执行最终验证,并从mozilla-release存储库发布版本.这些存储库中的每一个都作为单独的克隆进行维护.
从一个分支移动到另一个分支的实际分支机制有点复杂.所有分支都有共同的历史记录,但由于极光和beta分支在预先发布的过程中被选中的安全性和稳定性修复移植到它们,因此它们具有不同的历史.确切的过程记录在本段开头的链接中,但它归结为:"标记mozilla-central存储库;标记并关闭当前的mozilla-aurora头;将mozilla-central推向mozilla-aurora作为新头".对于极光 - >β重复相同的过程.
从开发到极光或beta分支的后向移植修复只是移植变更集的问题.hg transplant如果您愿意,可以使用该命令,我记录了我在博客上的操作方式.
总而言之,对于大多数项目而言,这可能是过度的.我们使用单独的存储库克隆而不是命名分支,因为我们对命名分支的工具不是很好,我们实际上更喜欢它给我们的隔离.您可以在这里使用命名分支来实现更轻量级的进程,只需在准备就绪时从默认分支创建一个新的命名分支,并在默认情况下继续开发时根据需要进行后端修复.