将实验历史记录保存在Mercurial中的共享存储库中

时间:2011-04-20 15:10:13

标签: version-control mercurial

我对Mercurial很新,但我看到使用Mercurial的一个优点是,在编写功能时,您可以更自由地进行实验,检查更改,共享它们等,同时仍保持“干净”回购完成的功能。

这个问题是历史问题之一。如果我尝试了6种不同的方法来使某些东西发挥作用,那么现在我对所有错误的所有历史都感到困惑。我想要做的是完成并清理我的更改并将它们“折叠”成一个可以推送到共享存储库的变更集。由于我可能从共享存储库中提取新的变更集,并将这些变更集与我自己的变更集混合在一起,这一点很复杂。

我知道这样做的最好方法是使用 hg export 来创建自克隆以来的更改补丁,克隆新的存储库,并将补丁应用到新的存储库。

这些步骤似乎有点麻烦且容易搞砸,特别是如果这种方法推广到整个开发团队,其中一些人有点抵制变化(不要让我开始)。 TortoiseHg使这个过程稍好一些,因为你可以突出显示你想要包含在导出中的变更集。

我的问题是:我是否比这更复杂?是否有更好的工作流程可以用来缓解我的烦恼?期望一个干净的历史,在一个变更集中包含整个(小型)功能是不是太过分了?

或者也许我的整个问题可以通过这种方式总结出来:

mercurial中是否有相同的效果? Collapsing a git repository's history

2 个答案:

答案 0 :(得分:3)

虽然我认为您应该重新考虑在Mercurial中使用分支(根据我对您帖子的评论),但使用命名分支并不能真正帮助您保持无用或不必要的历史记录 - 它只是对它们进行了一些组织。

我会推荐这些工具的组合:

  1. mercurial queues
  2. histedit(未与Hg一起分发)
  3. mq变更集条功能
  4. 在推送到一个有福的或主要的回购之前,重做一个混乱的历史。最简单的方法是使用strip永久删除没有子项的任何变更集。完成后,您可以使用mqhistedit来组合,重定位或修改现有提交。 Histedit甚至会让您重做与变更集相关的评论。

    一些陷阱:

    在您的开头段落中,您提到在功能开发期间共享更改集。请理解,一旦您共享了变更集,使用mq或histedit或strip进行修改并不是一个好主意。使用这些扩展可能会导致修订哈希值发生变化,这会使它们看起来像是其他人的新变更集。

    另外,我同意Paul Nathan的观点,即mq(和histedit)是强大的功能,很容易破坏历史。在使用这些扩展之前制作安全克隆是个好主意。

答案 1 :(得分:1)

命名分支是最简单的解决方案。每种实验方法都有自己的分支。这保留了实验的历史。

下一个解决方案是为每个实验准备一个新的克隆。工作的人被推回主要的回购。

下一个解决方案 - 也许你真正想要的 - 是mq扩展,它可以将一系列补丁“压缩”成一个提交。我认为mq是“先进的”,并且“容易意外地在脚下拍摄自己”。我也不在乎压缩我的提交 - 我喜欢将我的版本历史记录作为参考。