Encontrar errores al bisectar (search) el historial de revisión y confirmaciones no comprobables (revisiones)

La mayoría de las herramientas de control de versiones modernas tienen un command para encontrar un cambio que introdujo un error por búsqueda binaria (bisección) de un historial. Tal command puede estar incorporado o puede proporcionarse como extensión o complemento. Los ejemplos incluyen git-bisect en Git, " hg bisect" en Mercurial (anteriormente disponible como extensión hbisect ), y el complemento bzr-bisect para Bazaar.

El desafío es hacerlo de forma automática o semiautomática incluso en presencia de un historial no lineal (puntos de ramificación y fusiones). El objective es, en general, encontrar una revisión "incorrecta" en un número mínimo de pasos o, para mayor detalle, encontrar un compromiso para evaluar que, si es posible, divide el gráfico de confirmaciones para evaluar (DAG de confirmaciones) por la mitad. Este problema está resuelto, creo, muy bien.

Pero existe un problema con las confirmaciones no comprobables , por ejemplo, si algún código de revisión ni siquiera comstack, o si se comstack, no se inicia / ejecuta (o no encuentra errores relacionados con el que está buscando). Esto significa que en lugar de simplemente marcar commit como "bueno" o "malo", ahora tiene tres estados posibles:

  • bien – el error no está presente
  • malo – comportamiento con errores
  • unknown (no comprobable ): no se sabe si el error está presente

Algunos sistemas de control de versiones (SCM, por sus siglas en inglés) le permiten "omitir" dichos commits, usualmente yendo a la revisión principal como la que se probará a continuación.


Las preguntas son:

  • Si se ocupó de tal situación, lo que significa que usó la bisección y tropezó con revisiones no comprobables, ¿cuál es en su experiencia la distribución de tales comprobaciones no comprobables? ¿Ocurren de forma aislada (compromiso único no comprobable) o aparecen en intervalos (las revisiones a..b no se pueden verificar)? ¿Se encontró en una situación en la que tuvo que omitir el compromiso después del compromiso?

  • ¿Hay algún model matematical (como el bisectriz simple de la list / historia lineal, e incluso para bisectar el DAG arbitrario de las revisiones) o el algorithm (quizás heurístico), que permiten optimizar la omisión de confirmaciones no comprobables. El objective es volver a minimizar (en promedio) el número de versiones de las testings en presencia de confirmaciones no comprobables (o errores no relacionados).

  • ¿Utiliza el sistema de control de versiones, o algún add-on / extension / plugin para el sistema de control de revisiones, o alguna herramienta de terceros que implemente dicho algorithm, además de permitir simplemente "omitir" commits no comprobables al ir a la revisión de vecinos? ¿Qué es este VCS o herramienta? ¿Qué algorithm usa (si lo sabes)?

Esperemos que esto conduzca a errores de búsqueda aún más fáciles (semi) automatizados …


Agregado 06-06-2009:
Al usar funciones avanzadas de Git, hay una situación en la que puede tener una twig completa de confirmaciones no comprobables (o al less difíciles de probar), es decir, donde utiliza la combinación de " subtree " para unir historias de dos proyectos separados (por ejemplo, kernel completo de Linux) con algún controller desarrollado por separado con la combinación de "subtree"). Esto es algo que debe tenerse en count cuando se presenta un algorithm para tratar las confirmaciones no comprobables: con el historial no lineal puede haber una twig completa de confirmaciones no comprobables, y el algorithm debe tener en count la topología (algo).

Lo que ha sido registrado, obviamente, no puede ser ayudado. Las grandes bases de código en las que he trabajado requieren todos los check-ins para build realmente. Esto se hizo haciendo que los desarrolladores enviasen sus cambios al server de check-in, que tendría una queue de cambios a la espera de entrar. Cada cambio se genera para todas las plataforms de destino en el order en que se envía. Si la compilation falla, el check-in es rechazado. Si tiene éxito, se ejecuta un set de testings de regresión / unidad automatizadas. Si alguna testing falla, el check-in es rechazado. Si tiene éxito, el check-in se confirma en el repository.

Si tiene un sistema como este, networkinguce drásticamente el número de revisiones no modificables / no comprobables. Las comstackciones erróneas están limitadas a administradores de depósito que hacen cosas alocadas fuera del server de logging.

En entornos donde tal opción no está presente, no tengo un análisis estadístico riguroso, pero he encontrado que las revisiones anecdóticamente indestructibles ocurren en los bolsillos. Un check-in arruinará un montón de cosas y luego habrá una serie de pequeños check-ins que intentan corregir el problema. Entonces las cosas en general están bien por un time.

Podría networkingefinir los elementos individuales de su algorithm de bisección / búsqueda binaria para que sean intervalos de revisiones con estados adyacentes "desconocidos" en lugar de revisiones únicas.

En otras palabras, si durante su búsqueda binaria encuentra un estado desconocido, comienza haciendo una sub búsqueda hacia adelante y hacia atrás para encontrar los límites del range de revisión que arrojan las respuestas definitivas para usted. Esto probablemente sea una búsqueda lineal en ambas direcciones, por lo que será un poco más lento, tendrías que estar asumiendo que la mayoría de las revisiones no son inalterables.

Esto finalmente dará como resultado una serie de revisiones donde apareció el error, por ejemplo, en algún lugar entre la revisión (58,63). Tendría que search manualmente este range.

Solo una idea: sé que uno de los otros problemas en los que estás pensando es probar en presencia de ruido. Una forma de pensar en omisiones sería tratarlos como respondiendo aleatoriamente bien / mal, y usar un algorithm de bisección que sea robusto para tales errores, por ejemplo: http://www.disp.uniroma2.it/users/grandoni/FGItcs. pdf "Clasificación y búsqueda resilientes óptimas en presencia de fallas de memory". I. Finocchi, F. Grandoni y GF Italiano.

El efecto de aplicar ese algorithm a git-bisect sería dividir en dos puntos de salto y volver a ejecutar la búsqueda cuando se descubra que se ha seguido la twig incorrecta. A diferencia del documento anterior, usted sabe qué puntos no eran confiables, por lo que podría retroceder.

    Intereting Posts