Mercurial bisect 有啥用？

Posted 2023-02-19

【中文标题】Mercurial bisect 有啥用？

【英文标题】：What is Mercurial bisect good for?Mercurial bisect 有什么用？

【发布时间】：2011-04-01 20:05:54

【问题描述】：

我一直在阅读有关hg bisect 的信息，能够知道哪个版本引入了错误很有趣，但我想知道人们将这些信息用于什么目的。我唯一能想到的就是尝试缩小哪些日期可能需要数据修复，如果它是导致某种形式的无效数据的错误。

更新： 我想我在发布这个之前完全误解了目的。我在想我会进行调试并找到哪一行引入了错误，然后使用 bisect。似乎 bisect 是我不必花时间猜测错误可能在哪里并放置断点或记录的一种方式。相反，我应该编写一个现在失败的小测试，通过过去的修订并让 bisect 告诉我问题出在哪里。

【参考方案1】：

bisect 命令可帮助您找到引入错误的变更集。经常发生的情况是，您意识到某些东西已经损坏并且已经损坏了一段时间。使用hg bisect，您可以准确判断它何时损坏。当您知道这一点时，解决问题通常要容易得多。

它是这样工作的。您首先重置 bisect 状态并将当前版本标记为错误，因为它包含错误：

$ hg bisect --reset
$ hg bisect --bad

然后您在历史中跳转到您希望该错误不存在的点：

$ hg update -r -100
89 files updated, 0 files merged, 30 files removed, 0 files unresolved

您必须在此版本中测试您的软件，如果错误不存在，那么您可以将其标记为良好：

$ hg bisect --good
Testing changeset 11964:79bd860b8eb7 (81 changesets remaining, ~6 tests)
36 files updated, 0 files merged, 22 files removed, 0 files unresolved

当您将其标记为好时，Mercurial 会将您的工作副本更新到大致介于好和坏变更集之间的位置。您现在必须测试此变更集并将其标记为好/坏。

$ hg bisect --good
Testing changeset 11985:81edef14922e (41 changesets remaining, ~5 tests)
23 files updated, 0 files merged, 26 files removed, 0 files unresolved

我会继续这样做，直到 Mercurial 将搜索范围缩小到单个变更集：

$ hg bisect --bad
Testing changeset 11975:21884b433c51 (20 changesets remaining, ~4 tests)
18 files updated, 0 files merged, 8 files removed, 0 files unresolved
$ hg bisect --good
Testing changeset 11980:c443e95d295b (10 changesets remaining, ~3 tests)
5 files updated, 0 files merged, 10 files removed, 0 files unresolved
$ hg bisect --good
Testing changeset 11982:56d9b73487ff (5 changesets remaining, ~2 tests)
2 files updated, 0 files merged, 4 files removed, 0 files unresolved
$ hg bisect --bad
Testing changeset 11981:518b90d66fad (2 changesets remaining, ~1 tests)
2 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ hg bisect --bad
The first bad revision is:
changeset:   11981:518b90d66fad
user:        Pradeepkumar Gayam <[e-mail]>
date:        Wed Aug 18 05:55:56 2010 +0530
summary:     tests: unify test-merge8

您仍然需要自己进行调试，但是使用hg bisect 可以让您不必跟踪您已经测试过哪些变更集以及您还需要测试哪些变更集。您可以为此使用一堆便利贴，但让 Mercurial 来做会更好。当变更集图由于合并而非线性时尤其如此。

总而言之，hg bisect 可帮助您在对数时间内搜索错误的变更集，而无需跟踪您在搜索中的位置。

【讨论】：

此外，如果您可以将错误缩小到变更集，很多时候您可以更容易地看到错误被引入的位置（因为很多时候只更改了几十行）。当您想象在诸如 Linux 内核（git bisect 被大量使用）之类的东西中跟踪回归时，您可以很容易地看到为什么这比尝试调试整个项目要快。

@TomMarthenal：这是非常重要的一点，我应该已经提到了。

【参考方案2】：

很明显，如果您知道导致错误的变更集，您就可以减少您必须查看的代码量。错误的来源可能并不总是很清楚，实际错误可能出现在软件的某些不同部分。因此，您可以将精力集中在变更集中的几行上，而不是启动调试器并随机放置断点。

需要注意的一点是，bisect 的效率与良好的提交策略非常相关。如果创建包含数百行的巨大提交，整个过程可能几乎没有用，而针对每个变更集类型的提交集中一个单一的更改会使您的生活变得更加轻松。像在 Git 中那样进行激进的变基（修改历史）也可能使此操作变得更加困难。

【参考方案3】：

从错误的症状来看，它的原因可能并不明显 - 例如。您可能会收到非常一般的错误或不清楚的错误消息。使用hg bisect 可以找到原因。

【参考方案4】：

追踪引入错误的变更集。我认为很明显这是非常有用的。如果您的软件突然出现故障，并且您不知道是哪个更改导致了 bug 平分，则可以轻松追踪该更改。我完全不明白你在说什么约会。

【讨论】：

为了能够编写脚本来测试修订版，我必须找到错误所在并进行测试。就日期而言，我可以判断我是否在 7 月 1 日提交了某些内容，并于 7 月 15 日发布到我们的生产环境中，我必须进行数据修复，我知道我只需要使用比 7 更新的数据/ 15.所有这些信息都在注释中提供，所以我不确定 bisect 有什么帮助。

就像你说的，你必须找到bug在哪里。 Bisect 对此有所帮助。如果您知道 7/15 之前的任何事情都是好的，那么您仍然需要找到导致 7/15 之后的错误的变更集。这正是 bisect 的好处。你在 7 月 15 日给它一个变更集，你知道这是好的，而 head 失败了，它让你快速进行二进制搜索以找到罪魁祸首。