为啥 Mercurial 只有一级回滚？

Posted 2023-02-18

【中文标题】为啥 Mercurial 只有一级回滚？

【英文标题】：Why does Mercurial only have one level of rollback?为什么 Mercurial 只有一级回滚？

【发布时间】：2011-03-05 09:33:33

【问题描述】：

我了解回滚的限制和care required in its use，但我只是想知道为什么只有一个级别的回滚。

我猜这是一个设计决定，存储多个先前的事务状态以处理多级回滚的麻烦比它的价值更麻烦。

【问题讨论】：

据我了解，您的猜测非常准确。反复无常的方式是“一切都是不可变的”..所以如果您需要回滚 8 次修订前提交的内容，“hg”方式是引入一个新的更改来实现它。

【参考方案1】：

只有一个级别的回滚，因为回滚从未真正打算作为一项功能。回滚存在，并且有一个奇怪的名字，因为它源于 mercurial 的提交/推送/拉取事务系统。

如果网络推送进入并且完成了 99%，然后连接丢失，则不应让存储库处于不一致的状态。为了确保可以丢弃不完整的更改，在任何写入完成之前创建“在任何事情发生之前”指针，如果更改被中止，则所有内容都将重置为该状态 - 回滚。

rollback 命令实际上只是在成功完成后“失败”了之前的操作。它只是在设计了必要的交易安全性之后“免费”的东西。

当使用controlling hook 之类的东西时，可以定义必须通过的检查/测试，以便推送或提交成功完成。为了不成功完成，必须可以撤消正在进行的提交，但这也不需要多个级别。

正如 VonC 正确指出的，回滚可能非常危险。许多人回滚他们已经推送的更改，然后当其他这些更改在后续拉取时返回时会变得非常困惑。 hg backout 命令几乎总是一个更好的主意。

另请注意，您可以通过执行以下操作轻松模拟回滚到任何时间点：

hg clone -r last_revision_I_want repo_with_things_I_do_not_want new_repo_with_only_good_stuff

【参考方案2】：

诀窍是：hg rollback 不仅仅是重置一些提交，它重置与存储库关联的所有数据和元数据。 它实际上有no equivalent in Git，是一个相当危险的机制。 它可能被误用为通过重置历史来重写历史的一种方式，并且can "reset" more than you wanted。 允许在不止一个层面上这样做太危险了。

当仅涉及resetting/rewriting changeset （根据设计，它们是不可变的）时，extensions like MQ 更适合。

【讨论】：

我同意 - 绝对要避免的事情 - 我使用 MQ，所以我从来没有使用过它。这似乎是一个奇怪的限制 - 如果您要允许它，为什么不允许超过一个级别的回滚。