Asa*_*ers 25 version-control mercurial dvcs bisect
我一直在阅读hg bisect和有趣的是能够知道哪个版本引入了一个错误,但我想知道人们使用这些信息的原因.我唯一能想到的是尝试缩小哪些日期可能需要数据修复,如果它是导致某种形式的无效数据的错误.
更新: 我想在发布之前我完全误解了目的.我在想我会进行调试,找到引入错误的行,然后使用bisect.似乎bisect是一种方式让我不必花时间猜测bug可能在哪里并放置断点或记录.相反,我应该编写一个现在失败的小测试,传入过去的修订版并让二等分告诉我问题的来源.
Mar*_*ler 73
该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可以帮助您在对数时间内搜索错误的变更集,而无需跟踪搜索的位置.