私は読んでいてhg bisect、どのリビジョンがバグを導入したかを知ることができるのは興味深いですが、人々がこの情報を何に使用しているか知りたいです. 私が考えられる唯一のことは、何らかの形式の無効なデータをもたらすバグである場合、データの修正が必要な日付を絞り込もうとすることです.
更新: これを投稿する前に、目的を完全に誤解していたと思います。私はデバッグを行い、どの行がバグを導入したかを見つけてから、bisect を使用することを考えていました。bisect は、バグがどこにあるかを推測したり、ブレークポイントを配置したり、ログを記録したりするのに時間を費やす必要がないように思えます。代わりに、現在失敗し、過去のリビジョンで合格し、bisect に問題の原因を教えてもらう小さなテストを作成する必要があります。
この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 が検索を 1 つの変更セットに絞り込むまで、この作業を続けます。
$ 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、検索のどこにいるかを追跡する必要なく、対数時間で障害のある変更セットを検索するのに役立ちます。
バグを導入した変更セットを追跡するため。これが非常に便利であることは明らかだと思います。ソフトウェアに突然障害が発生し、どの変更がバグの原因となったのかわからない場合は、バグを分割することでその変更を簡単に追跡できます。デートに関しては何を言っているのかさっぱりわかりません。
バグの症状からは、その原因が正確にわからない場合があります。たとえば、非常に一般的なエラーや不明確なエラー メッセージが表示される場合があります。を使用hg bisectすると、原因を見つけることができます。
バグの原因となった変更セットがわかれば、調べる必要のあるコードの量を絞り込むことができることは明らかです。バグの原因は常に明確であるとは限らず、実際のエラーはソフトウェアの別の部分に現れる場合があります。したがって、たとえばデバッガーを起動してブレークポイントをランダムに配置する代わりに、変更セットの数行に労力を集中できます。
注意すべきことの 1 つは、bisect の効率は、優れたコミット戦略と非常に相関関係があるということです。何百行もの巨大なコミットを作成すると、プロセス全体がほとんど役に立たなくなる可能性がありますが、コミットのチェンジセット タイプごとに 1 つの変更に焦点を当てると、作業が非常に楽になります。Git のように積極的なリベース (履歴の変更) を行うと、この操作がさらに難しくなる可能性があります。