26

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

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

4

4 回答 4

76

该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 <in3xes@gmail.com>
date:        Wed Aug 18 05:55:56 2010 +0530
summary:     tests: unify test-merge8

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

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

于 2010-08-23T11:26:23.963 回答
8

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

于 2010-08-20T19:20:14.700 回答
1

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

于 2010-08-20T19:24:14.067 回答
0

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

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

于 2010-08-20T19:35:19.603 回答