为什么Mercurial只有一级回滚？

Question

我理解回滚的限制以及在使用时需要注意的问题，但我想知道为什么只有一个回滚级别。

我猜测这是一种设计决策，存储多个之前的事务状态以处理多个回滚级别的麻烦比它所值得的更麻烦。

- Nick Pierpoint

---

据我理解，你的猜测相当准确。Mercurial 的方式是“一切都是不可变的”..所以如果你需要回滚到 8 个版本之前提交的某些内容，'hg' 的方式就是引入一个新的更改来实现它。 - Tim Post

Answer 1

只有一层回滚是因为回滚从未被真正地作为一个功能来设计。回滚存在并拥有奇怪的名称，是因为它起源于Mercurial的提交/推送/拉取事务系统。如果一个网络推送正在进行并且完成了99%，然后连接断开了，仓库不应该保留在不一致的状态。为确保可以丢弃未完成的更改，在执行任何写操作之前会创建一个“发生任何事情之前”的指针，如果更改被中止，则将所有内容重置为该状态--回滚。实际上，“回滚”命令只是在成功完成先前操作之后“失败”该操作而已。这只是在必要的事务安全性被设计后“免费提供”的东西。当使用像控制挂钩这样的东西时，可以定义必须通过检查/测试才能成功完成推送或提交。为了不成功完成，必须能够撤消正在进行的提交，但这也不需要多个级别。正如VonC正确指出的那样，回滚可能非常危险。许多人回滚了他们已经推送的更改，然后在随后的拉取中混淆不清其他更改的情况。hg backout命令几乎总是一个更好的选择。还要注意，您可以通过执行以下操作轻松模拟到任何时间点的回滚：

hg clone -r last_revision_I_want repo_with_things_I_do_not_want new_repo_with_only_good_stuff

- Ry4an Brase

Answer 2

技巧在于：hg rollback 不仅可以重置某些提交，还可以重置与存储库相关的所有数据和元数据。
它实际上在Git中没有等价项，并且是相当危险的机制。
它可能会被误用为通过重置来重写历史记录，而且会 “重置”超出您想要的范围。
允许在多个级别上进行这样的操作太危险了。

当仅涉及重置/重写更改集（按设计是不可变的）时，像MQ这样的扩展程序更加合适。

- VonC

---

我同意 - 绝对是要避免的事情 - 我使用MQ，所以我从来没有使用过它。只是看起来有点奇怪的限制 - 如果你要允许它，为什么不允许多个回滚级别呢？ - Nick Pierpoint