4

每次保存任何内容时，我都将 IDE 设置为在本地提交。理想情况下，我希望保留一份未经审查的记录，以备不时之需，以备不时之需。但大多数时候它使我的历史变得详细。

我想知道一个很好的策略来保留这段历史，但大部分时间都可以忽略它。每次保存时，我的 IDE 都会运行我自己的脚本，所以我可以控制它。

我对 Mercurial 很陌生，所以我在这里可能只需要一个基本的答案。但是，在提交、合并和报告时我应该执行哪些步骤才能在很大程度上忽略这些自动提交，但实际上不会压缩它们？还是我最好放弃并只是挤压？

关于如何用评价很高的评论进行壁球的相关问题表明保留该历史记录可能会更好

编辑 - 我的观点是，如果 Mercurial 想要保留您的所有历史记录（我同意），它应该让您过滤该历史记录以避免看到您可能想要压缩的内容。我宁愿不压扁，我只是寻求一种策略的帮助（在常规使用中，尽管并非总是如此）使它看起来尽可能像我压扁我的历史一样。

4

4 回答 4

4

您想在您的存储库中保留详细的历史记录，但您希望拥有（并能够导出）仅包含“合理”修订集的理想化历史记录，对吗？我可以同情。

解决方案一：用标签标记历史中有趣的点，学会忽略它们之间的所有杂乱无章的点。

解决方案2：使用两个分支并合并。在分支中进行开发default，并保持并行分支release。（你可以称它为clean，但实际上你是在管理发布）。每当default处于您想要检查点的稳定状态时，如果您愿意，切换到分支release并将--的当前状态分批合并到其中。default如果您从不直接向 提交任何内容release，则永远不会发生合并冲突。

 (original branch) --o--o--o--o--o--o--o    (default)
          \              \        \
           r   ... ...  --r--------r        (release)

结果：您可以更新到任何修订版release并期望正常运行状态。你可以运行hg log -r release，你只会看到选择的检查点。您可以检查完整的日志以了解一切是如何发生的。缺点：因为release分支依赖于default，所以你不能把它推送到另一个仓库而不default带它。由于hg glog -r release重复合并，也会看起来很奇怪。

解决方案 3：如上使用命名分支，但使用rebase扩展而不是合并。它可以选择复制而不是直接移动重新设置的变更集；它有一个选项--collapse可以将一组修订转换为一个修订。r1:tip每当您有一组要完成的修订时，请将它们从to复制如下：defaultrelease

hg rebase --source r1 --dest release --keep --collapse

这会将 ONE 修订版推到 r1 的开头，release这相当于整个变更集从 r1 到default. 该--keep选项使其成为副本，而不是破坏性的重写。优点是release分支看起来就像你想要的那样：漂亮干净，你可以推送它而不用拖拽默认分支。缺点是您无法将其阶段与 中的修订相关联default，因此我建议您使用方法 2，除非您确实必须隐藏中间修订。（另外：分批压缩你的历史并不容易，因为 rebase 将移动/复制“源”修订的所有后代。）

所有这些都需要你做一些额外的工作。这是不可避免的，因为 mercurial 无法知道您想要压缩哪些修订集。

于 2012-10-31T22:34:58.977 回答
3

它应该让您过滤该历史记录，以避免看到您可能想要压缩的东西

Mercurial 有这方面的工具。如果您只是不想看到（hg log我想在 中） - 使用 revsets 过滤这些变更集：

hg log -r "not desc('autosave')"

或者，如果您使用 TortoiseHg，只需转到 View -> Filter Toolbar，然后在工具栏中输入“not desc('autosave')”。瞧，您的自动保存条目已从主列表中隐藏。

于 2012-10-27T05:04:29.437 回答
2

如果您确实希望保留Ctrl-S回购历史记录中的所有微小更改，并且只log显示重要更改集的子集，那么您始终可以tag将“重要”更改集别名log为log -r tagged(). 或者您可以将相同的原则与其他一些revset descriptor一起使用，例如在自动提交的消息中包含文本“autosave”并使用log -r keyword(autosave)，这将向您显示所有非自动保存的提交。

为了实现您的目标，至少在我接近它的时候，我会使用mq扩展并在每次保存时自动提交补丁队列存储库。然后，当您完成“白痴摸索”后，您可以hg qfinish将补丁作为可以推送的单个变更集。您应该（一如既往！）将更改集中在一个概念或步骤上（例如“修复保存按钮”），但这将记录为实现目标所采取的所有小步骤。

你需要

  • hg qinit --mq一次初始化补丁队列​​仓库（仅供参考：存储在\.hg\patches\）
  • hg qnew fixing-the-save-btn创建补丁

然后每次保存在 IDE 中

  • hg qrefresh更新补丁
  • hg commit --mq在补丁队列 repo 中进行小改动

当你完成

  • hg qfinish fixing-the-save-btn将补丁转换为要推送的变更集

这样可以使您的 repo 本地化与每次保存时更改的内容保持一致，但仅在完成时推送变更集。您还可以qpop或qpush更改您正在处理的项目。

如果您尝试使用 squash 方法，那么当您压缩变更集时，您会丢失摸索的历史记录。要么这样，要么你会被困在试图将工作迁移到“真实”存储库/从“真实”存储库迁移，我可以根据经验告诉你，你不想这样做。:)

于 2012-10-26T19:22:39.603 回答
1

我建议你使用分支。当您开始一个新功能时，您会创建一个新分支。您可以在该分支中尽可能多地提交。完成后，将功能分支合并到主干中。这样，您基本上将历史分为两类：一类是细粒度的（特征分支中的历史），另一类是粗粒度的（主干中的历史）。您可以使用以下命令轻松查看其中任何一个：hg log --branch <branch-name>。

于 2012-10-29T03:31:41.960 回答