Arquitectura de Buildbot

Buildbot permite configurar de varias formas el modo en que va a obtener el código fuente del proyecto y cómo realizará las actualizaciones subsiguientes. Por ejemplo, el modo “update” hace que las operaciones de checkout/update se ejecuten en el directorio de trabajo, y no en uno independiente, como en el modo “copy” o “clobber”, que mantienen un directorio separado y limpio del repositorio (en el caso de Mercurial, “copia de trabajo” en el caso de Subversion) y hacen una copia del mismo para realizar la compilación (esto asegura que siempre se compile todo y que no influyan archivos generados en procesos anteriores, además de otros problemas menos comunes pero que existen).

El problema que estuve teniendo es cuando utilizo Mercurial. Al intentar traer el código fuente, Buildbot entra en un bucle infinito donde realiza el checkout (clone), borra el directorio, otra vez clone y asi… me pareció rarísimo el comportamiento. Versiones anteriores de Buildbot con versiones anteriores de Mercurial funcionan bien.

En uno de los pasos para realizar el checkout/update, Buildbot verifica si ha cambiado la URL del repositorio. Si esto es así, entonces hace clobbering, o sea, vuelve a bajar todos los cambios (checkout) y obviamente no realiza un update, aunque el modo no sea “clobbering”. Para saber si dicha URL ha cambiado, ejecuta un “hg paths default” en el directorio de trabajo y lo compara con la URL asignada en el archivo de configuración central del Build Master.

El bug está en que al ejecutar “hg paths default” Mercurial 1.3.1 devuelve el password oculto con asteriscos:

$ hg paths default 

http://miltondp:***@url.mi_proyecto.com/path/al/repo

… y, obviamente, la URL asignada en el archivo de configuración está completa (sin el password oculto). Al compararse ambas, son distintas, y por lo tanto siempre se hace clobbering.

Rápidamente me fijé si Mercurial poseía alguna opción para mostrar el password en la salida de “hg paths”. No posee dicha opción por lo visto, pero me encontré con un parche que alguien envió alguna vez, el cual parece que nunca fue incluido. El mismo agrega la opción “–show-passwords” para mostrar la URL completa al ejecutar “hg paths”. Lo pueden bajar aquí. El archivo a parchear es “/usr/lib/pymodules/python2.6/mercurial/commands.py”.

También hay que parchear Buildbot para que utilice esta nueva opción al comparar los repositorios. Este otro parche lo pueden bajar desde este lugar. Tener en cuenta que el archivo a parchear tiene el mismo nombre que el de Mercurial. El path del mismo es “/usr/lib/python2.6/dist-packages/buildbot/slave/commands.py”

No se olviden de reiniciar el servicio de Buildbot, y de borrar los archivos .pyc de Python (por lo visto a veces funciona aunque no lo borremos). Ahora el ciclo funciona como uno espera:

De todas formas, parece que ese no es el uso principal. Piensen que están colaborando con algún proyecto, donde utilizan Mercurial (o cualquier DCVS). Están trabajando en una nueva funcionalidad. Sabemos que los commits son inmutables. No sería conveniente que hagan commits en su repositorio local y luego intenten enviar todos esos cambios (que tendrán varios merges de por medio quizá) para la revisión, porque la dificulta. Lo conveniente sería (según explican al introducirnos en Mq) enviar parches con el trabajo finalizado. De esta forma podríamos ir manteniendo distintos parches de acuerdo a nuestro trabajo e ir actualizándolos a medida que avancemos. Como Mercurial Queues integra los parches a todo el sistema, los mismos son tratados como changesets, por lo tanto podemos pensar en los mismos como commits mutables: terminamos con nuestro trabajo y actualizamos el commit. Al día siguiente nos damos cuenta de que había un error y lo volvemos a actualizar con el nuevo trabajo. Incluso, como dije, podemos descartarlos, reordenarlos, etc. Y a medida que el trabajo se hace más complejo, podemos tener distintos parches, cada uno con cambios relacionados.

Yo tengo hecho mi CV en LaTeX bajo Mercurial. Después de un tiempo manteniéndolo y actualizándolo, me encontré colocando notas en forma de TODO o FIXME para recordar actualizar ciertas cosas, o trabajos sobre el mismo a medio hacer. El problema es que cuando tengo que enviar una versión limpia de mi CV, debo compilar una versión “estable” quitando todas estas modificaciones no terminadas. Por lo tanto es ideal usar Mq en esta situación: mantengo estos “features” o recordatorios como parches o commits mutables. Cuando quiero agregar algún recordatorio o estoy trabajando en una ampliación o reestruración, trabajo sobre los parches y los voy actualizando. Cuando veo que ya están listos, los transformo en changeset normales (o sea, inmutables). Cuando quiero compilar una versión estable, quito todos los parches, quedando así una versión limpia lista para enviar.

Algunos comandos como para que se den una idea de cómo funciona:

$ hg qinit
$ hg qnew nueva.funcionalidad
# Ahora estoy trabajando en el parche "nueva.funcionalidad". Realizo cambios, agrego archivos con "hd add", etc... trabajo comúnmente como siempre.
$ hg qrefresh
# con este comando actualizo el parche en el que estoy trabajando. Todos los cambios realizados son guardados ahora en "nueva.funcionalidad".

Si quiero quitar todos los parches aplicados ejecuto:

$ hg qpop -a

Si quiero aplicar todos los parches:

$ hg qpush -a

Si quiero moverme a un parche específico:

$ hg qgoto nombre.parche

Uno de los inconvenientes que surgió después de haberme encontrado con esta fantástica herramienta, fue que quería subir estos parches al repositorio. De esta forma, podría acceder a ellos y modificarlos desde cualquier máquina. Sin embargo esto no es trivial. La solución pasa por armar otro repositorio en el servidor. Por lo tanto el directorio local .hg/patches que posee todos los parches, se transforma en otro repositorio Mercurial y lo tratamos como tal: de vez en cuando subimos al repo de parches nuestros cambios a los mismos. Esto puede parecer tedioso, pero Mercurial ofrece unas utilidades que facilitan las cosas.

Me parece que es una extensión muy útil. En lo personal no me fue fácil agarrarle la mano rápidamente. Aunque como todo, para dominarlo hay que ponerlo en práctica.

La idea es que en los tres paneles de meld, a la izquierda tengamos la versión de base, en la que se basan (valga la redundancia) nuestras modificaciones y las de la otra rama, en el medio nuestro archivo, y a la derecha el del otro. Trabajamos con la vista del medio, realizamos la fusión y guardamos los cambios al finalizar. Así resolvemos el conflicto.

Sin embargo no es ese el orden en el que aparecen los archivos en meld cuando trabajamos con Mercurial. Buscando en la ayuda de configuración, he encontrado estas opciones que podemos utilizar en nuestro ~/.hgrc, y así resolver este inconveniente:

[merge-tools]
meld.executable = meld
meld.args = $base $local $other
meld.priority = 1

Hace un tiempo vengo estudiando este sistema de control de versiones distribuído, hecho principalmente en Python, y que lo utilizan algunos grandes proyectos como Mozilla, OpenJDK, NetBeans, etc. En este post, quería compararlo con Subversion, con respecto a mantener distintas ramas de desarrollo.

Aclaro que si bien no tengo una experiencia real con ambos sistemas en el tema, como la podría tener algún desarrollador de un proyecto grande de Software Libre, leyendo los manuales, viendo los ejemplos y utilizándolo en pequeños proyectos con pocos desarrolladores uno puede darse una idea de cómo son las cosas a gran escala.

En muchos lugares se habla de las bondades de los sistemas de control de versiones distribuidos. Una de las ventajas que tienen (entre muchas otras), según se dice, es la facilidad para manejar branches, donde se mencionan las deficiencias de Subversion para manejar varias ramas de desarrollo.

Este post puede servir para alguien que esta pensando en alguna herramienta de versionado, donde se esperan utilizar varios branches en el proyecto, como para poder ver de forma sencilla cómo manejan esto ambos sistemas. Esa “forma sencilla” de verlo podría significar también una divergencia importante con la práctica. Así que si piensan que algo es incorrecto, los invito a dejar un comentario.

En fin, ¿cómo se realizan estas operaciones en ambos sistemas?

Aquí con branch me refiero a una línea de desarrollo para agregar un nuevo feature o corregir un bug, etc. La aclaración es importante, porque en Mercurial casi siempre trabajamos con branches. Si hago un pull y traigo changesets (es decir commits) puede que surjan nuevas ramas. Este no es el significado al que me refiero aquí.

Subversion

En Subversion, no existe el concepto de branch. Un branch es simplemente una copia de un directorio a otro lugar. Uno mismo es el que le da ese significado.

Puedo hacer la copia directamente en el repositorio (donde automáticamente hago un commit):

$ svn copy http://svn.example.com/repos/calc/trunk \
           http://svn.example.com/repos/calc/branches/my-calc-branch \
      -m "Creating a private branch of /calc/trunk."

Committed revision 341.

Si tengo la copia de trabajo correspondiente a todo el repositorio en mi máquina (incluyendo las típicas carpetas trunk, branches y tags):

$ svn copy trunk branches/my-calc-branch
$ svn status
A  +   branches/my-calc-branch
$
$ svn commit -m "Creating a private branch of /calc/trunk."
Adding         branches/my-calc-branch
Committed revision 341.

Luego simplemente comienzo a trabajar en esa carpeta, en mi nuevo branch. Sin embargo, hay una serie de inconvenientes. No podemos dejar que la línea principal de desarrollo se aleje demasiado de nuestro branch (supongamos que estamos agregando un nuevo feature), ya que al intentar fusionar todo luego de un largo tiempo, podemos terminar por frustrarnos. Esto, obviamente, no se aplica sólo a Subversion.

Entonces, periódicamente, traemos los cambios hechos en trunk a nuestra copia de trabajo, que corresponde a la rama en la que estamos trabajando:

$ svn merge -r 100:200 http://svn.example.com/repos/trunk my-working-copy
...
$ svn commit -m "Sync with trunk"

El comando “svn merge” es muy similar a “svn diff”, pero aplica los cambios a mi copia de trabajo.

Como dice en el libro de Subversion, fusionar los cambios suena fácil, pero puede resultar en un dolor de cabeza. Yo, el usuario, soy el que tengo que controlar los merges que hago. Subversion (las versiones menores a las 1.5) no lo hacen. Esto significa que puedo fusionar los cambios dos veces, por ejemplo, o puedo comparar dos cosas sin ningún tipo de relación e intentar aplicar los cambios resultantes a mi copia de trabajo. Cuando ejecuto un comando parecido al de arriba, Subversion no sabe qué significan esos cambios. Simplemente se aplican a la copia de trabajo.

Supongamos que el día al fin ha llegado, y quiero traer a trunk mi nuevo feature, desarrollado en mi branch. Como dice en el libro, si están pensando en comparar la última revisión de trunk con la última del branch, se equivocan: ¿qué pasaría con los cambios hechos en trunk que nunca sucedieron en el branch? Se borrarían, y eso no es lo que queremos.

Lo que hay que hacer es comparar el estado inicial del branch con su estado final. De esta forma adiciono a trunk los cambios que he realizado en mi branch. Para esto tengo que saber en qué revisión creé mi branch. Una forma fácil de averiguar esto con Subversion:

$ svn log --verbose --stop-on-copy \

http://svn.example.com/repos/calc/branches/my-calc-branch

…
------------------------------------------------------------------------
r341 | user | 2002-11-03 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines
Changed paths:
   A /calc/branches/my-calc-branch (from /calc/trunk:340)

$

El procedimiento completo, sacado del libro, es este:

$ cd calc/trunk
$ svn update
At revision 405.

$ svn merge -r 341:405 http://svn.example.com/repos/calc/branches/my-calc-branch
U   integer.c
U   button.c
U   Makefile

$ svn status
M   integer.c
M   button.c
M   Makefile

# ...examine the diffs, compile, test, etc...

$ svn commit -m "Merged my-calc-branch changes r341:405 into the trunk."
Sending        integer.c
Sending        button.c
Sending        Makefile
Transmitting file data ...
Committed revision 406.

Noten lo descriptivos que son los mensajes de commit. Esto es necesario hacerlo así, para saber luego, por ejemplo, que ya se han aplicado los cambios del branch, y qué cambios involucran. Es información crítica: supongan que siguen trabajando en el branch y quieren traer los nuevos cambios hechos. Necesitan saber qué cambios ya han sido aplicados para no volver a traerlos a trunk. Para hacer eso, básicamente se ejecutan los comandos anteriores, alterando el rango de las revisiones según corresponda.

Cuando estaba aprendiendo Subversion, leí muy por arriba estas cosas, ya que no eran las que iba a utilizar habitualmente, y además me pareció un poco complicado, con varias advertencias de posibles problemas al fusionar cambios, etc. Por eso estoy copiando los ejemplos del libro, y ahora, en realidad, estoy viendo bien cómo funciona.

Sin embargo una de las cosas que sí aprendí a hacer ya que me parecieron muy útiles, que tiene relación con esto, es “deshacer” un commit, o sea, anular sus cambios. La forma de hacerlo es la siguiente:

$ svn merge -r 303:302 http://svn.example.com/repos/calc/trunk
U  integer.c

$ svn status
M  integer.c

$ svn diff
…
# verify that the change is removed
…

$ svn commit -m "Undoing change committed in r303."
Sending        integer.c
Transmitting file data .
Committed revision 350.

Simplemente se invierten, como habrán notado, el orden de las revisiones a comparar, resultando en un patch contrario al que aplica, en este caso, el commit 303, provocando la anulación de sus modificaciones. Sin embargo, si quiero traer un objeto eliminado de vuelta, no utilizo el comando anterior, sino “svn copy”.

Todas estas cosas que pueden parecer complicadas (y de hecho lo son), parecen estar comenzando a cambiar a partir de Subversion 1.5. Por ejemplo, algunos de los nuevos features, que podemos leer en las release notes, son merge tracking y la resolución interactiva de conflictos. Sin embargo el primero, como se menciona, posee una funcionalidad básica.

Mercurial

Veamos ahora cómo es esto en Mercurial. Aquí un desarrollador no posee únicamente la copia de trabajo, como en Subversion, sino el repositorio completo. Una forma fácil de crear un branch en Mercurial es clonar mi repositorio actual. Supongamos que tengo uno en la carpeta myproject:

$ hg clone myproject myproject-1.0
updating working directory
2 files updated, 0 files merged, 0 files removed, 0 files unresolved

De esta forma puedo comenzar a trabajar en el nuevo branch creado:

$ cd myproject-1.0
$ echo 'Alguna nueva funcionalidad' > algunArchivo
$ hg commit -A -m 'Nuevo feature!'
adding algunArchivo

Con esta manera de crear ramas, hay una relación uno-a-uno entre los branches en los que estoy trabajando y las carpetas existentes. Si necesito centralizar el branch porque voy a trabajar con otros desarrolladores y queremos tener un lugar común donde subir los cambios, entonces puedo subir el repositorio por FTP por ejemplo, a la carpeta donde el script hgwebdir.cgi verifique la existencia de repositorios. Con copiar la carpeta allí y realizar unas simples configuraciones en el archivo .hg/hgrc ya estamos. Otra es, si tenemos acceso shell a la máquina servidor, clonar el repositorio allí mismo.

Estos son los repositorios Mercurial de Mozilla. Allí se pueden ver varios. En uno de ellos se hace un merge con otro, como se puede ver en este changeset.

Si corrijo algún error en mi branch myproject-1.0, seguramente también queramos llevar esas correcciones en la linea principal de desarrollo (digamos, trunk), en el cual, supongamos, también se han hecho modificaciones. Para hacer esto, nos ubicamos en el directorio en donde queremos llevar los cambios (la linea principal en este caso), y ejecutamos un pull indicando la carpeta del branch:

$ cd myproject/
$ hg pull ../myproject-1.0
pulling from ../myproject-1.0
searching for changes
adding changesets
adding manifests
adding file changes
added 2 changesets with 2 changes to 2 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)
$ hg merge
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)

Con el comando pull lo que hago es traer los cambios (changesets) hechos en el repositorio que le paso como argumento. Cada changeset sabe cuál es su padre, por lo tanto al pullear, se armarán las ramas que sean necesarias. Después del pull, yo sigo en la revisión en la que estaba. Nada ha cambiado en mi copia de trabajo, simplemente se sincronizó mi repositorio actual con el otro.

Notar que Mercurial me avisa que han quedado varios heads: un head es un changeset sin hijos. Con el comando “hg view” puedo ver el panorama actual del repositorio:

El comando “hg merge” fusiona, justamente, mi copia de trabajo con otra revisión. Lo que hace es aplicar a mi copia de trabajo todos los cambios de la otra rama, según corresponda.

Notar que si bien estamos diciendo que utilizamos un branch, myproject-1.0, estos dos heads aquí, también representan branches, pero del tipo “little picture” (como se explica en el libro de Mercurial). Este tipo de branches aparecen todos los días, cuando pulleamos cambios de otro repositorio: son parte del trabajo cotidiano. En cambio el branch myproject-1.0 es del tipo “big picture”, ya que vamos a trabajar en la versión 1.0, corrigiendo errores, etc.

Si “hg merge” detecta conflictos, se ejecuta algún visor de diferencias, como meld o kdiff3. Mercurial se encarga de buscarlo en el sistema, o podemos setearlo nosotros en el archivo ~/.hgrc. Estos visores tienen tres vistas: a la izquierda están mis cambios, en el medio el resultado, y a la derecha los cambios del otro. Entonces es muy sencillo resolver el conflicto.

Como Mercurial nos recuerda después de ejecutar el merge, no debemos olvidarnos de hacer un commit aquí. Este commit tendrá como padres a los dos heads actuales:

Si bien estamos hablando de un sistema distribuído, obviamente que si queremos compartir cambios, la manera sencilla de trabajar es poner un repositorio central visto por todos los desarrolladores, al cual todos puedan subir sus cambios, y del cual puedan bajar los cambios de otros. Si realizo commits en mi repositorio local y quiero subirlos al remoto (con un push), Mercurial me avisará si es que estoy por generar heads remotamente. Si esto sucede, tengo que hacer un pull, mergear los dos heads, y luego subir el resultado.

Esta situación es similar en Subversion a cuando intentamos hacer un commit y nos dice que tenemos que ejecutar un update antes: entonces aplica los cambios en nuestra copia de trabajo, resolvemos los conflictos si es necesario, y realizamos un commit.

Otra forma de crear un branch en Mercurial, es hacerlo en el mismo repositorio, con Named Branches. Así nos ahorramos el tener que subir algo al servidor. Por defecto, si no hemos cambiado nada, trabajamos en el branch llamado default.

Con el comando “branches” puedo ver cuáles hay en mi repositorio:

$ hg branches
default                        0:34b3e0e21c40

Y con el comando “branch” veo en qué branch estoy trabajando ahora:

$ hg branch
default

Supongamos que hemos hecho unos commits en la rama default:

$ hg log
changeset:   1:7c0e8fbd1fb1
user:        Milton Pividori <mimail@proveedor.com>
date:        Sun Oct 12 13:52:18 2008 -0300
summary:     Agrego chau.cs

changeset:   0:936587b0804a
user:        Milton Pividori <mimail@proveedor.com>
date:        Sun Oct 12 13:52:05 2008 -0300
summary:     Agrego hola.cs

Entonces, para comenzar a trabajar en un nuevo branch, digamos myproject-1.0, hacemos:

$ hg branch myproject-1.0
marked working directory as branch myproject-1.0
$ hg branch
myproject-1.0

Como nos indica el comando “branch”, ahora estamos trabajando en nuestro nuevo branch recién creado. El comando por sí sólo no hace nada. Simplemente le indica a Mercurial que a partir de ahora, vamos a comenzar a trabajar en este branch. Si hacemos un commit, Mercurial marcará el changeset como perteneciente a ese branch, y así con todos los changesets siguientes. Supongamos que hemos realizado tres commits más en este nuevo branch:

$ hg log -b myproject-1.0
changeset:   4:188979745f99
branch:      myproject-1.0
tag:         tip
user:        Milton Pividori <mimail@proveedor.com>
date:        Sun Oct 12 14:05:53 2008 -0300
summary:     Agrego comoestas.cs

changeset:   3:06231db27675
branch:      myproject-1.0
user:        Milton Pividori <mimail@proveedor.com>
date:        Sun Oct 12 14:01:02 2008 -0300
summary:     Nuevo feature en chau.cs

changeset:   2:d2d1fd5f5b39
branch:      myproject-1.0
user:        Milton Pividori <mimail@proveedor.com>
date:        Sun Oct 12 14:00:48 2008 -0300
summary:     Nuevo feature en hola.cs

Y supongamos que el trabajo en la rama default continúa con más commits. Entonces el panorama en el repositorio luce como esto:

La rama de la izquierda corresponde a default, y la de la derecha a myproject-1.0. Para moverme entre los distintos branches de un repositorio, utilizo el comando “hg update nombreBranch”. Si después de eso realizo más commits, obviamente, pertenecerán al branch al que me he movido.

Supongamos que mi trabajo en el branch myproject-1.0 ha terminado, y quiero fusionar los cambios con default. Para eso me muevo al branch default (notar que llamo branch a la linea principal de trabajo), o sea a donde quiero llevar mis cambios, y utilizo, nuevamente, el comando “hg merge” seguido del nombre del branch del que quiero traer los cambios:

$ hg update default
2 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ hg merge myproject-1.0
merging chau.cs
merging hola.cs
1 files updated, 2 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ hg ci -m "Merge de myproject-1.0 a default"

El nuevo commit pertenecerá al branch default. Este comportamiento es el esperado: fusiono los cambios de un branch dentro del que yo estoy trabajando.

Aquí pueden ver una captura de meld cuando se presenta un conflicto, y a continuación el estado final del repositorio, luego de fusionar los cambios de mi branch a default:

Veamos cómo deshacer un commit con Mercurial. Supongamos que éste es el estado actual del repositorio:

Si me doy cuenta que el changeset 4 (“Bug fix en bar”) es incorrecto, entonces lo deshago con el comando “hg backout”:

$ hg backout --merge 4
reverting bar
created new head
changeset 7:cad3793b208a backs out changeset 4:e56015c82591
merging with changeset 7:cad3793b208a
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)

El comando “backout” crea una nueva revisión teniendo como padre aquella que quiere deshacer. Por lo tanto se generará un nuevo head. La opción “–merge” automáticamente fusiona los cambios con la otra cabeza.

Después del commit, el repositorio queda así:

Al mensaje de log lo genera Mercurial.

Conclusiones finales

Creo que realizar branches y luego fusionarlos es bastante más fácil en Mercurial. No tengo que ver en qué revisión comencé el branch y calcular el rango como en Subversion. No tengo que preocuparme de no aplicar dos veces los mismos cambios. Si sigo trabajando en mi branch, traer los nuevos cambios es muy sencillo, ya que Mercurial es el que controla esto. No hace falta ser descriptivo con los logs de los commits, porque con “hg view” puedo ver gráficamente el panorama y saber qué commits fueron realizados para fusionar cambios.

Revertir el cambio de una revisión parece sencillo en ambos, salvo que en Mercurial el comando para resucitar un objeto eliminado, que en definitiva es anular un commit, sigue siendo “backout”. En Subversion había que utilizar “copy”. De todas formas habría que probarlos en situaciones reales en contextos más complicados.

A grandes rasgos (y según lo que yo entendí y veo más notorio), la gran diferencia entre los sistemas de control de versiones centralizados como Subversion o CVS y los distribuidos como Git, Mercurial y Bazaar, es que los primeros imponen más restricciones que sus pares distribuidos. En Subversion por ejemplo, si accedo a mi repositorio vía Internet, y en algún momento no tengo conexión, entonces no puedo hacer commits. Si quiero ver los logs de algunas revisiones o realizar otras operaciones que no sean updates o commits, necesito acceder al repositorio central, lo que es más lento.

En los sistemas centralizados hay un servidor central, y varias copias de trabajo, una por cada desarrollador. En los sistemas distribuidos puede o no haber un servidor central con el repositorio, pero la diferencia es que todos los desarrolladores tienen el repositorio completo, no una copia de trabajo. Es decir que cada persona posee la versión actual más toda la historia del proyecto en su computadora, lo que permite operar en modo offline. Esto puede parecer ineficiente, pero de hecho no lo es: los grandes proyectos de Software Libre como Linux, NetBeans, OpenJDK, Mozilla, y en un futuro GNOME también, usan estos sistemas, ya que ofrecen grandes beneficios (especialmente para los proyectos Open Source). Imagínense hacer commits, crear branches, etc, sin necesidad de conexión. Y cuando termino mi trabajo, luego de revisarlo bien, ahí recién puedo subir todo, o sino decirle a mi colega desarrollador que actualice su repositorio desde el mío.

En definitiva, con un sistema distribuido puedo trabajar con menos restricciones que con uno centralizado.

Estos días estaba leyendo el capítulo 9 de un libro de Mercurial. Uno de los subcapítulos está dedicado a la búsqueda de revisiones o changesets que han introducido bugs. Realizar esto con Mercurial es fácil, ya que tengo todo el repositorio disponible para trabajar offline, por lo que las búsquedas entre changesets son mucho más rápidas.

Imagínense que encontramos un error en nuestro proyecto, y queremos ver en qué revisión fue introducido para realizar un backout del mismo. Para esto, en Mercurial, podemos utilizar el comando “bisect”. Hagamos el ejemplo que se muestra en el libro para ser breves y correctos. Ejecutamos:

$ hg init test
$ cd test

Con un script bash creo automáticamente algunos changesets, e introduzco un bug en el commit 22:

#!/bin/bash

buggy_change=22
for (( i = 0; i < 35; i++ )); do
	if [[ $i = $buggy_change ]]; then
		echo 'i have a gub' > myfile$i
		hg commit -q -A -m 'buggy changeset'
	else
		echo 'nothing to see here, move along' > myfile$i
		hg commit -q -A -m 'normal changeset'
	fi
done

Ejecuto el script en el directorio del repositorio. Esperamos unos momentos a que finalice. Encontrarán varios archivos myfile*. Actualmente estamos, obviamente, en la revisión tip (o HEAD en Subversion):

$ hg parent
changeset:   34:a1c784850dca
tag:         tip
user:        Milton Pividori <miltondp@gmail.com>
date:        Wed Sep 03 10:53:58 2008 -0300
summary:     normal changeset

$

Para saber si en la revisión actual se encuentra el bug, simplemente ejecutamos esto:

$ grep 'i have a gub' myfile*
myfile22:i have a gub
$

Para comenzar las pruebas, ejecutamos:

$ hg bisect --reset

Le indicamos a Mercurial que la revisión tip (o sea, la 34 en nuestro caso, y la actual de la copia de trabajo), es “bad”, ya que contiene el bug (o mejor dicho, posee esa característica de la cual queremos saber en qué changeset se introdujo. Digo esto, porque podríamos querer buscar qué changeset solucionó determinado bug, con lo cual la revisión “bad” sería la que no tiene el error):

$ hg bisect --bad
$

De alguna forma, sabemos que la revisión 10 no tiene el bug, así que la marcamos como “good”. En este caso y a los fines del ejemplo saber esto es sencillo, pero digo “de alguna forma” porque en la práctica debería ser la revisión más tardía sin el bug, lo cual podría llevarnos un tiempo.

$ hg bisect --good 10
Testing changeset 22:3103b305bc80 (24 changesets remaining, ~4 tests)
0 files updated, 0 files merged, 12 files removed, 0 files unresolved
$

Vean que Mercurial nos está diciendo cuántos changesets va a procesar, y la cantidad aproximada de tests que vamos a tener que realizar. Como utiliza búsqueda binaria o dicotómica, la cantidad de comparaciones o pruebas es logarítmica, lo cual obviamente reduce mucho el proceso de búsqueda.

Al ejecutar el comando anterior, la copia de trabajo se actualiza a la revisión 22 ( (34 + 10) / 2 = 22 ). Ahora realizamos el test en esta revisión y le decimos a Mercurial si la misma es “bad” o “good”:

$ grep 'i have a gub' myfile*
myfile22:i have a gub
$

Lo anterior nos indica que es “bad”. Claro que esto se puede automatizar tanto como queramos. Podemos crear un script que haga casi todo:

#!/bin/bash

if ( grep -q 'i have a gub' myfile* )
then
	result=bad
else
	result=good
fi
echo this revision is $result
hg bisect --$result

Lo ejecutamos:

$ ./test.sh
this revision is bad
Testing changeset 16:2deb07b463cf (12 changesets remaining, ~3 tests)
0 files updated, 0 files merged, 6 files removed, 0 files unresolved
$

Ahora Mercurial nos sitúa en la revisión 16 ( (10 + 22) / 2 = 16 ). Faltan unos 3 tests aún. Volvemos a correr nuestro script:

$ ./test.sh
this revision is good
Testing changeset 19:dc33070521ae (6 changesets remaining, ~2 tests)
3 files updated, 0 files merged, 0 files removed, 0 files unresolved

$ ./test.sh
this revision is good
Testing changeset 20:98953c61831c (3 changesets remaining, ~1 tests)
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

$ ./test.sh
this revision is good
Testing changeset 21:d1616a476608 (2 changesets remaining, ~1 tests)
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

$ ./test.sh
this revision is good
The first bad revision is:
changeset:   22:3103b305bc80
user:        Milton Pividori <miltondp@gmail.com>
date:        Wed Sep 03 10:53:56 2008 -0300
summary:     buggy changeset

La revisión que introdujo el bug que estamos buscando es la 22. Con algún tipo de software que automatice la práctica de “Integración continua”, podríamos indicar que seamos notificados cuando alguna revisión o changeset (independientemente del sistema de control de versiones utilizado) no pasa las pruebas o no compila por ejemplo. Esto nos habilitaría a detectar exactamente qué commit introdujo errores o bugs.

Sin embargo, puede pasar que no haya una prueba determinada que me indique que cierta revisión tiene un error, sino que nos demos cuenta de eso más tarde, y nos interese saber en qué changeset se introdujo el mismo para revertirlo (obviamente que esto no es tan sencillo. Habría que estudiar ese changeset para saber dónde está el error). Luego de introducir la prueba de unidad que verifica ese error que estamos buscando, podemos utilizarla para encontrar la revisión que introdujo el problema con algún script y el comando “bisect” que vimos anteriormente, automatizando la operación. Luego, en caso de ser los cambios de dicha revisión simples como el ejemplo, podemos revertirlo de esta forma en Mercurial (primero vuelvo a la revisión tip con “hg update”):

$ hg update
$ hg backout -m "Elimino el bug" 22
removing myfile22
created new head
changeset 35:37d16077cdac backs out changeset 22:a7281f19f281
the backout changeset is a new head - do not forget to merge
(use "backout --merge" if you want to auto-merge)

Ahora hay dos “heads” en mi repositorio (un “head” es un changeset que no tiene hijos), por lo tanto debemos, como nos está indicando Mercurial, hacer un merge entre ambos (podríamos haber utilizado la opción –merge del comando backout directamente).

Con el comando “hg view” podemos ver esto gráficamente:

Notar que el “padre” de la nueva revisión 35 (que soluciona el bug) es el changeset 22. O sea que este cambio no introduce todos los cambios entre ésta revisión y la 34. Por lo tanto debemos hacer, como ya nos había indicado Mercurial, un merge:

$ hg merge
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ hg status
R myfile22
$ hg commit -m "Merge hecho"
$

Otra vez, ejecuto “hg view” para ver todo esto gráficamente:

Notar que los changeset de la nueva revisión tip 36 son los commits 34 y 35.

Si bien nunca hice estas cosas con Subversion, por lo que me acuerdo de haber leído, en este sistema de control de versiones hacer esto no es tan sencillo. Justamente una de las críticas a Subversion es que es fácil hacer branches, pero difícil fusionarlos.