version control - que - ¿Para qué sirve Mercurial Bisect?

meta tags importantes

Question

He estado leyendo sobre hg bisect y es interesante poder saber qué revisión introdujo un error, pero me gustaría saber para qué personas usan esta información. Lo único que se me ocurre es tratar de reducir qué fechas pueden necesitar una corrección de datos si se trata de un error que produce algún tipo de datos no válidos.

actualización: creo que entendí mal el propósito antes de publicar esto. Estaba pensando en hacer la depuración y encontrar qué línea (s) introdujo el error y luego usar bisect. Parece que bisect es una manera para que no tenga que perder tiempo adivinando dónde podría estar el error y colocando puntos de interrupción o registro. En su lugar, debería escribir una pequeña prueba que falle ahora, pase en una revisión anterior y que bisect me diga dónde se origina el problema.

Answer 1

El comando bisect ayuda a encontrar el conjunto de cambios que introdujo un error. A menudo sucede que te das cuenta de que algo está roto y que se ha roto por un tiempo. Con hg bisect , puede averiguar exactamente cuándo se rompió. Cuando lo sabes, a menudo es mucho más fácil solucionar el problema.

Funciona así. Para empezar, restablece el estado de bisecto y marca la revisión actual como mala, ya que contiene el error:

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

Luego retrocedes en la historia hasta un punto en el que esperas que el error no esté presente:

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

Debe probar su software en esta revisión y, si el error no está presente, puede marcarlo como correcto:

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

Cuando lo marcó como bueno, Mercurial actualizó su copia de trabajo en un lugar aproximadamente en el medio entre los conjuntos de cambios buenos y malos. Ahora tienes que probar este conjunto de cambios y marcarlo como bueno / malo.

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

Continúo así hasta que Mercurial redujo la búsqueda a un solo conjunto de cambios:

$ 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

Aún tiene que hacer la depuración usted mismo, pero usar hg bisect evita hacer un seguimiento de los conjuntos de cambios que ya ha probado y que aún necesita probar. Podría usar un montón de notas post-it para esto, pero es mucho mejor dejar que Mercurial lo haga. Esto es especialmente cierto cuando el gráfico de conjunto de cambios es no lineal debido a las combinaciones.

Así que, en general, hg bisect ayuda a realizar una búsqueda de un conjunto de cambios defectuoso en el tiempo logarítmico, sin que tenga que realizar un seguimiento de dónde se encuentra en la búsqueda.

Answer 2

Es bastante obvio, que si conoce el conjunto de cambios que causó el error, puede reducir la cantidad de código que tendrá que revisar. La fuente de los errores puede no estar siempre clara, y el error real puede aparecer en alguna parte diferente del software. Entonces, en lugar de iniciar, por ejemplo, el depurador y colocar puntos de interrupción al azar, puede concentrar su esfuerzo en las pocas líneas del conjunto de cambios.

Una cosa que se debe tener en cuenta es que la eficiencia de bisect está muy en correlación con una buena estrategia de compromiso. Si crea compromisos gigantes, con cientos de líneas, todo el proceso puede ser casi inútil, mientras que un solo cambio por tipo de conjunto de cambios hace que la vida sea mucho más fácil para usted. Hacer rebasado agresivo (modificar el historial), como en Git, también podría hacer esta operación mucho más difícil.

Answer 3

Para rastrear el conjunto de cambios que introdujo un error. Creo que es obvio que esto es muy útil. Si su software falla repentinamente y no sabe qué cambio causó el error, la bisecta hace que sea más fácil rastrearlo. No entiendo en absoluto lo que estás diciendo sobre las fechas.

Answer 4

Puede que no sea obvio por el síntoma de un error exactamente cuál es su causa, por ejemplo, puede que obtenga un error muy genérico o un mensaje de error poco claro. Usar hg bisect te permite encontrar la causa.