Чем хорош Mercurial bisect?

Чтобы отследить набор изменений, в котором была обнаружена ошибка. Думаю, очевидно, что это очень полезно. Если ваше программное обеспечение внезапно выходит из строя, и вы не знаете, какое изменение вызвало ошибку, рассечение пополам позволяет легко отследить это изменение. Я совершенно не понимаю, что вы говорите о свиданиях.

Команда 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

Когда вы отметили его как хорошее, 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 <[email protected]>
date:        Wed Aug 18 05:55:56 2010 +0530
summary:     tests: unify test-merge8

Вам по-прежнему придется выполнять отладку самостоятельно, но использование hg bisect избавляет вас от необходимости отслеживать, какие наборы изменений вы уже протестировали, а какие еще нужно протестировать. Вы можете использовать для этого кучу заметок, но гораздо приятнее позволить Mercurial сделать это. Это особенно верно, когда график набора изменений является нелинейным из-за слияний.

Таким образом, hg bisect помогает вам выполнить поиск ошибочного набора изменений за логарифмическое время, без необходимости отслеживать, где вы находитесь в поиске.

Из симптомов ошибки может быть неочевидно, какова ее причина - например, вы можете получить очень общую ошибку или нечеткое сообщение об ошибке. Использование hg bisect позволяет найти причину.

Совершенно очевидно, что если вы знаете набор изменений, вызвавший ошибку, вы можете сузить объем кода, который вам придется просмотреть. Источник ошибок не всегда может быть ясен, а фактическая ошибка может появиться в какой-то другой части программного обеспечения. Таким образом, вместо запуска, например, отладчика и случайного размещения точек останова, вы можете сосредоточить свои усилия на нескольких строках в наборе изменений.

Следует отметить одну вещь: эффективность деления пополам во многом коррелирует с хорошей стратегией фиксации. Если вы создаете гигантские коммиты с сотнями строк, весь процесс может оказаться почти бесполезным, в то время как целенаправленное одно изменение для каждого типа коммитов значительно облегчит вам жизнь. Выполнение агрессивной перебазировки (изменение истории), как в Git, также может значительно усложнить эту операцию.