我一直在阅读有关hg bisect 的信息，能够知道哪个版本引入了错误很有趣，但我想知道人们将这些信息用于什么目的。我唯一能想到的就是尝试缩小哪些日期可能需要数据修复，如果它是导致某种形式的无效数据的错误。
更新： 我想我在发布这个之前完全误解了目的。我在想我会进行调试并找到哪一行引入了错误，然后使用 bisect。似乎 bisect 是我不必花时间猜测错误可能在哪里并放置断点或记录的一种方式。相反，我应该编写一个现在失败的小测试，通过过去的修订并让 bisect 告诉我问题出在哪里。
【问题讨论】：
标签： version-control mercurial dvcs bisect
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 可帮助您在对数时间内搜索错误的变更集，而无需跟踪您在搜索中的位置。
【讨论】：
git bisect 被大量使用）之类的东西中跟踪回归时，您可以很容易地看到为什么这比尝试调试整个项目要快。
很明显，如果您知道导致错误的变更集，您就可以减少您必须查看的代码量。错误的来源可能并不总是很清楚，实际错误可能出现在软件的某些不同部分。因此，您可以将精力集中在变更集中的几行上，而不是启动调试器并随机放置断点。
需要注意的一点是，bisect 的效率与良好的提交策略非常相关。如果创建包含数百行的巨大提交，整个过程可能几乎没有用，而针对每个变更集类型的提交集中一个单一的更改会使您的生活变得更加轻松。像在 Git 中那样进行激进的变基（修改历史）也可能使此操作变得更加困难。
【讨论】：
从错误的症状来看，它的原因可能并不明显 - 例如。您可能会收到非常一般的错误或不清楚的错误消息。使用hg bisect 可以找到原因。
【讨论】：
追踪引入错误的变更集。我认为很明显这是非常有用的。如果您的软件突然出现故障，并且您不知道是哪个更改导致了 bug 平分，则可以轻松追踪该更改。我完全不明白你在说什么约会。
【讨论】：