代码之家 › 专栏 › 技术社区 › Asa Ayers

水银对分有什么用?

bisect dvcs mercurial version-control

25

Asa Ayers · 技术社区 · 14 年前

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

更新: 我想在我发布这个之前我完全误解了目的。我在想,我会做调试,找出哪行(s)介绍了错误,然后使用对分。对分似乎是一种方法,我不必花时间猜测错误可能在哪里,放置断点或日志记录。相反,我应该写一个小测试,现在失败了,通过了过去的修订,并平分告诉我问题的根源。

4 回复 | 直到 9 年前

1

8

Raoul Duke 14 年前

跟踪引入错误的变更集。我认为这显然是非常有用的。如果您的软件突然出现故障,并且您不知道是哪个更改导致了错误,那么对分可以很容易地跟踪该更改。我一点也不明白你在说什么约会。

2

75

klaus se 8 年前

这个 bisect hg 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

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

$ 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

总之, 帮助您在对数时间内搜索错误的变更集,而不必跟踪您在搜索中的位置。

3

1

Richard Fearn 14 年前

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

4

0

Kai Inkinen 14 年前

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

需要注意的一点是,平分的效率与良好的提交策略密切相关。如果创建具有数百行的巨型提交,那么整个过程可能几乎毫无用处,而每个变更集类型的提交只关注一个更改,这会让您的生活变得更加轻松。在Git中进行积极的重定基(修改历史)也可能会使此操作变得更加困难。