我一直在阅读有关hg bisect的内容，有趣的是能够知道哪个版本引入了错误，但我想知道人们使用这些信息的原因。我唯一能想到的是尝试缩小哪些日期可能需要数据修复，如果它是导致某种形式的无效数据的错误。
更新 在发布之前，我想我完全误解了目的。我在想我会进行调试，找到引入错误的行，然后使用bisect。似乎bisect是一种方式让我不必花时间猜测bug可能在哪里并放置断点或记录。相反，我应该编写一个现在失败的小测试，传递过去的修订版，并将二等分告诉我问题的来源。
答案 0 :(得分：72)
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可帮助您在对数时间内搜索错误的变更集，而无需跟踪您在搜索中的位置。
答案 1 :(得分：5)
跟踪引入错误的变更集。我认为这显然非常有用。如果您的软件突然失败并且您不知道哪个更改导致了错误，则可以轻松跟踪该更改。我完全不了解你对约会的看法。
答案 2 :(得分：1)
从错误的症状中可能并不明显的原因是什么 - 例如您可能会收到非常一般的错误或错误的错误消息。使用hg bisect可以找到原因。
答案 3 :(得分：0)
很明显，如果您知道导致该错误的变更集，您可以缩小您需要查看的代码量。错误的来源可能并不总是很清楚，实际错误可能出现在软件的某些不同部分。因此，您可以将工作重点放在变更集中的几行上，而不是启动例如调试器，并随机放置断点。
应该注意的一点是，bisect的效率与良好的提交策略非常相关。如果创建具有数百行的巨型提交，整个过程可能几乎无用，而每个变更类型的提交集中一个单一的更改会让您的生活变得更加轻松。像在Git中那样进行积极的变基（修改历史记录）也可能使这个操作变得更加困难。