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

Question

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

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

Answer 1

Команда 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 <in3xes@gmail.com>
date:        Wed Aug 18 05:55:56 2010 +0530
summary:     tests: unify test-merge8

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

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

Answer 2

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

Answer 3

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

Answer 4

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

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