Для чего нужен Mercurial bisect?

Я читал о hg bisect и его интересно узнать, какая версия ввела ошибку, но я хотел бы знать, для чего люди используют эту информацию. Единственное, что я могу придумать, - это попытаться сузить, какие даты могут потребоваться для исправления данных, если это ошибка, которая приводит к некоторой форме недопустимых данных.

обновление: Я думаю, я полностью неправильно понял цель, прежде чем я разместил это. Я думал, что сделаю отладку и найду, в какую строку ввел ошибку, а затем использовал bisect. Кажется, bisect - это способ для меня не тратить время на угадывание, где может быть ошибка, и размещение контрольных точек или ведение журнала. Вместо этого я должен написать небольшой тест, который терпит неудачу, проходит в прошлой ревизии и имеет двоюродный ответ, расскажите мне, откуда возникла проблема.

Ответ 1

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

Ответ 2

Команда 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 <[email protected]>
date:        Wed Aug 18 05:55:56 2010 +0530
summary:     tests: unify test-merge8

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

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

Ответ 3

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

Ответ 4

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

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