Für was ist Mercurial halbiert gut?

Question

Ich habe über hg bisect gelesen und es ist interessant zu wissen, welche Revision einen Fehler eingeführt hat, aber ich würde gerne wissen, wofür diese Informationen verwendet werden. Das einzige, was mir einfällt, ist zu versuchen, einzugrenzen, welche Daten möglicherweise eine Datenbereinigung benötigen, wenn es sich um einen Fehler handelt, der zu einer Form ungültiger Daten führt.

update: Ich denke, ich habe den Zweck völlig missverstanden, bevor ich das gepostet habe. Ich dachte, dass ich das Debugging machen würde und finde heraus, welche Zeile (n) den Fehler eingeführt und dann halbieren. Es scheint, als wäre die Halbierung eine Möglichkeit für mich, keine Zeit damit zu verbringen, zu raten, wo der Fehler sein könnte, und Breakpoints oder Logging zu platzieren. Stattdessen sollte ich einen kleinen Test schreiben, der jetzt scheitert, eine vergangene Revision übergibt und mir halbiert habe, woher das Problem stammt.

Answer 1

Um das Changeset aufzuspüren, das einen Fehler einführte. Ich denke, es ist offensichtlich, dass dies sehr nützlich ist. Wenn Ihre Software plötzlich fehlschlägt und Sie nicht wissen, welche Änderung verursacht wurde, erleichtert es die Fehlerhalbierung, diese Änderung aufzuspüren. Ich verstehe überhaupt nicht, was Sie über Daten sagen.

Answer 2

Es ist nicht offensichtlich aus dem Symptom eines Fehlers genau, was seine Ursache ist - z. Sie könnten einen sehr allgemeinen Fehler oder eine unklare Fehlermeldung erhalten. Mit hg bisect können Sie die Ursache finden.

Answer 3

Es ist ziemlich offensichtlich, dass, wenn Sie den Changeset kennen, der den Fehler verursachte, Sie die Menge an Code eingrenzen können, die Sie sehen müssen. Die Fehlerquelle ist möglicherweise nicht immer eindeutig und der tatsächliche Fehler kann in einem anderen Teil der Software auftreten. Anstatt beispielsweise den Debugger zu starten und Breakpoints nach dem Zufallsprinzip zu platzieren, können Sie sich auf die paar Zeilen im Changeset konzentrieren.

Eine Sache, die beachtet werden sollte, ist, dass die Effizienz der Halbierung sehr viel mit einer guten Commit-Strategie korreliert. Wenn Sie riesige Commits mit Hunderten von Zeilen erstellen, ist der gesamte Prozess möglicherweise nahezu nutzlos, während eine einzige Änderung pro Changeset-Art von Commits das Leben für Sie wirklich viel einfacher macht. Aggressives Rebasieren (Ändern der Geschichte), wie in Git, könnte diese Operation auch viel schwieriger machen.

Answer 4

Der Befehl bisect hilft Ihnen, den Änderungssatz zu finden, der einen Fehler verursacht hat. Oft merkt man, dass etwas kaputt ist und dass es für eine Weile gebrochen ist. Mit hg bisect können Sie genau herausfinden, wann es kaputt ging. Wenn Sie das wissen, ist es oft viel einfacher, das Problem zu beheben.

Es funktioniert so. Sie beginnen mit den bisect Zustand zurückzusetzen und die aktuelle Version als schlecht markiert, da sie den Fehler enthält:

$ hg bisect --reset 
$ hg bisect --bad 

Sie dann in der Geschichte zurückspringen zu einem Punkt, wo Sie den Fehler Hoffnung nicht vorhanden ist:

$ hg update -r -100 
89 files updated, 0 files merged, 30 files removed, 0 files unresolved 

Sie haben Ihre Software bei dieser Revision zu prüfen und, wenn der Fehler nicht vorhanden ist, dann kann man es so gut markieren:

$ hg bisect --good 
Testing changeset 11964:79bd860b8eb7 (81 changesets remaining, ~6 tests) 
36 files updated, 0 files merged, 22 files removed, 0 files unresolved 

wenn Sie es so gut markiert, Mercurial aktualisiert Ihre Arbeits Kopieren Sie einen Platz ungefähr in der Mitte zwischen den guten und den schlechten Changesets. Sie müssen dieses Changeset jetzt testen und gut/schlecht markieren.

$ hg bisect --good 
Testing changeset 11985:81edef14922e (41 changesets remaining, ~5 tests) 
23 files updated, 0 files merged, 26 files removed, 0 files unresolved 

ich so weitermachen, bis Mercurial die Suche auf eine einzige changeset verringert hat:

$ 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 

Sie immer noch das Debuggen von selbst zu tun haben, aber hg bisect mit erspart Ihnen den Überblick über welche Change Sie haben bereits getestet und müssen noch getestet werden. Sie könnten dafür eine Reihe von Post-it-Notizen verwenden, aber es ist viel schöner, Mercurial dies tun zu lassen. Dies gilt insbesondere dann, wenn das Changeset-Diagramm aufgrund von Zusammenführungen nicht linear ist.

Alles in allem hilft hg bisect Sie eine Suche nach einem fehlerhaften Changeset in logarithmischer Zeit, ohne dass Sie verfolgen müssen, wo Sie in der Suche sind.