Для чего нужен Mercurial bisect?
Я читал о hg bisect , и мне интересно узнать, в какой версии была обнаружена ошибка, но я хотел бы знать, в чем люди используют эту информацию для. Единственное, о чем я могу думать, - это попытаться сузить круг дат, которые могут потребовать исправления данных, если это ошибка, которая приводит к некоторой форме неверных данных.
update: Думаю, я совершенно неправильно понял цель до того, как опубликовал это. Я думал, что займусь отладкой и найду, в какой строке (строк) возникла ошибка, а затем воспользуюсь пополам. Похоже, что деление пополам - это способ не тратить время на догадки, где может быть ошибка, и на размещение точек останова или ведение журнала. Вместо этого я должен написать небольшой тест, который сейчас терпит неудачу, проходит предыдущую ревизию и делит пополам, где возникает проблема.
4 ответа
Чтобы отследить набор изменений, в котором была обнаружена ошибка. Думаю, очевидно, что это очень полезно. Если ваше программное обеспечение внезапно выходит из строя, и вы не знаете, какое изменение вызвало ошибку, рассечение пополам позволяет легко отследить это изменение. Я совершенно не понимаю, что вы говорите о свиданиях.
По признаку ошибки может быть не очевидно, какова ее причина - например, вы можете получить очень общую ошибку или нечеткое сообщение об ошибке. Использование hg bisect позволяет найти причину.
Совершенно очевидно, что если вы знаете набор изменений, вызвавший ошибку, вы можете сузить объем кода, который вам придется просмотреть. Источник ошибок не всегда может быть ясен, и фактическая ошибка может появиться в какой-то другой части программного обеспечения. Таким образом, вместо запуска, например, отладчика и случайного размещения точек останова, вы можете сосредоточить свои усилия на нескольких строках в наборе изменений.
Следует отметить одну вещь: эффективность деления пополам во многом коррелирует с хорошей стратегией фиксации. Если вы создаете гигантские коммиты с сотнями строк, весь процесс может оказаться почти бесполезным, в то время как целенаправленное одно изменение для каждого типа коммитов значительно облегчит вам жизнь. Выполнение агрессивной перебазировки (изменение истории), как в Git, также может значительно усложнить эту операцию.
Команда 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 помогает вам выполнять поиск ошибочного набора изменений в логарифмическом масштабе, без необходимости отслеживать, где вы находитесь в процессе поиска.