Al conectar la segunda impresora, exactamente igual que la primera, la detección fue también satifactoria. Aunque surgió un pequeño gran problema: al imprimir sobre ésta última, la impresión se realizaba sobre la primera. Observando la configuración de ambas, me percaté de que tenían exactamente el mismo Device URI.

La solución fue bastante rápida: editar el archivo /etc/cups/printers.conf, y cambiar el device URI, que era algo así como “usb:/Samsung…” por “file:/dev/usblp0″, y la otra impresora por “file:/dev/usblp1″. Con esto el problema fue resuelto y todo comenzó a funcionar como uno esperaba. Aunque no tardó en surgir otro inconveniente.

Después de un tiempo de estar funcionando todo de mil maravillas, la cajera me comenta un día que, para sorpresa de ella, las facturas A se imprimían en la impresora para las facturas B, y viceversa. Me había comentado que no fue mucho problema, ya que simplemente cambió las hojas y tema resuelto. Pero desde ese mismo instante no me quedé muy tranquilo.

Después de un tiempo recibo una nueva llamada: las impresoras estaban enloquecidas. Todos los días, al encender la PC, los puertos se cambiaban. Lo que en el principio era una pequeña molestia, ahora se estaba transformando en una situación bastante irritante. No estaba seguro cómo solucionarlo, así que por lo tanto intenté una actualización del sistema, lo que en apariencias lo había solucionado. Duró uno o dos meses más hasta que el problema reapareció.

Entonces esa vez me puse a buscar un poco más, a preguntar, y me encontré con udev. Este componente del kernel Linux, encargado de gestionar dispositivos, permite, entre muchas cosas, crear reglas para: nombrarlos de una forma distinta (cambiar “sda1″ por “mi_disco”), agregar links simbólicos cuando se cumplan ciertas condiciones, ejecutar comandos ante ciertos eventos, y mil cosas más.

Lo que tuve que hacer, entonces, es buscar algún tipo de información en los atributos de cada impresora, que sea único para la misma. Para esto utilicé el comando udevadm:

$ udevadm info -a -p  $(udevadm info -q path -n /dev/usblp0)

[...]

  looking at parent device '/devices/pci0000:00/0000:00:1d.3/usb5/5-2':
    KERNELS=="5-2"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{configuration}==""
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bmAttributes}=="c0"
    ATTRS{bMaxPower}=="  0mA"
    ATTRS{urbnum}=="1368"
    ATTRS{idVendor}=="04e8"
    ATTRS{idProduct}=="3301"
    ATTRS{bcdDevice}=="0100"
    ATTRS{bDeviceClass}=="00"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bDeviceProtocol}=="00"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{bMaxPacketSize0}=="16"
    ATTRS{speed}=="12"
    ATTRS{busnum}=="5"
    ATTRS{devnum}=="2"
    ATTRS{version}==" 1.10"
    ATTRS{maxchild}=="0"
    ATTRS{quirks}=="0x0"
    ATTRS{authorized}=="1"
    ATTRS{manufacturer}=="Samsung Electronics Co., Ltd."
    ATTRS{product}=="ML-1660 Series"
    ATTRS{serial}=="Z526BKDZ800022B."

El atributo serial es el que difiere en cada impresora, por lo tanto utilicé éste para crear un archivo /etc/udev/rules.d/impresoras.rules con las siguientes reglas:

SUBSYSTEMS=="usb", ATTRS{product}=="ML-1660 Series", ATTRS{serial}=="Z526BKAZ301606A.", SYMLINK+="impr_fa"
SUBSYSTEMS=="usb", ATTRS{product}=="ML-1660 Series", ATTRS{serial}=="Z526BKDZ800022B.", SYMLINK+="impr_fb"

Una vez guardado el archivo, hacen un “service udev reload”, desenchufan y vuelven a enchufar las impresoras, y verán que aparecen los dispositivos “impr_fa” e “impr_fb”. Ahora estos serán siempre fijos y aputarán siempre al mismo dispositivo físico (en teoría, les cuento en unos meses). Tal cual lo que estaba buscando. Si hacemos un “ls” vemos:

$ ls -l /dev/impr*
lrwxrwxrwx 1 root root 7 2011-02-22 07:34 /dev/impr_fa -> usb/lp1
lrwxrwxrwx 1 root root 7 2011-02-22 10:25 /dev/impr_fb -> usb/lp0

Pueden encontrar más información sobre cómo escribir reglas udev en este link. A mí me vino muy bien para las impresoras, pero se podrían hacer cosas interesantes con pendrives y otros dispositivos.

Cuando les mostré esto a César y a Nacho, nos preguntábamos si en Windows será posible hacer algo similar. Una de las respuestas fue: “estas cosas [impresoras enloquecidas] no pasan en Windows” y “seguramente debe tener alguna forma de configurarlo”. Solo por curiosidad: ¿alguien tiene alguna información al respecto?

Ojalá los bindings para Mono no se retrasen mucho.

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:

Este post puede ser útil para los que utilicen el widget TreeView de Gtk+ (no importa el lenguaje mientras haya bindings), y necesiten activar por código celdas en modo edición. Hay algunas cuestiones a tener en cuenta.

Para el Proyecto Final de Carrera estamos desarrollando un sistema de nivel operativo, con funciones de facturación y demás. Necesitamos manejar un TreeView con campos editables, y al finalizar la edición de uno de ellos es necesario dar el foco a otro campo en modo edición, listo para que el usuario comience a cargar datos sin tocar el mouse.

Lo primero que hicimos fue conectar un método al evento Edited del CellRendererText de la columna correspondiente. De esta forma, cuando terminamos la edición en el primer campo, podemos colocar allí el código correspondiente para actualizar el modelo del TreeView y otras operaciones más, entre ellas (la que nos interesa) dar el foco al segundo campo en modo edición. La parte final de este método (el evento se activa al finalizar la edición) había quedado así:

/* ... */

this.tvItems.SetCursor(path,
					   this.tvcCodigoProducto,
					   true);

Hay que tener cuidado al utilizar la función SetCursor. En algunos casos, si no la usamos cuidadosamente, el TreeView no se comportará en forma correcta. Esos casos son por ejemplo cuando el usuario, al estar editando el campo, hace click en otra fila. Esto hace que se dispare el evento Edited, y por lo tanto se activa el modo edición en el segundo campo (SetCursor), pero el foco lo tiene otra fila, y esto hace que el funcionamiento sea incorrecto.

La solución es, antes de ejecutar SetCursor, verificar qué tipo de evento ha ocurrido. En nuestro caso, ejecutamos dicha función sólo si se ha oprimido la tecla Return. El código queda así:

/* Una vez editada la cantidad, automáticamente
 * pasamos el foco al campo de 'código' en modo
 * edición, pero en una nueva fila. A esto lo hacemos
 * únicamente si el usuario presionó la tecla Enter */

Gdk.Event ev = Gtk.Application.CurrentEvent;

if (ev.Type == Gdk.EventType.KeyPress) {
	Gdk.EventKey evKey = (Gdk.EventKey)ev;

	if (evKey.Key == Gdk.Key.Return)
		this.tvItems.SetCursor(path,
							   this.tvcCodigoProducto,
							   true);
}

Lo cual es más lógico también: si se hace click en otra fila, seguramente es porque se quiere editar otro ítem y por lo tanto no es correcto forzar el foco en otro lugar. Además, como se dijo, esto hacía que el TreeView quede en un estado inconsistente.

$ sl
El programa «sl» no está instalado actualmente.  Puede instalarlo escribiendo:
sudo apt-get install sl
bash: sl: orden no encontrada

La primera vez que lo vi me pareció extraño, así que instalé el paquete “sl” como me sugería. La descripción del paquete es esta:

Correct you if you type `sl' by mistake
Sl is a program that can display animations aimed to correct you
if you type 'sl' by mistake.
SL stands for Steam Locomotive.

Me imagino que tendrán ahora la intriga de qué es lo que pasa si ejecutan “sl”. Simplemente tengan cuidado

Escenario

La máquina que tendrá el servidor DHCP, TFTP y compartirá Internet es mi notebook, que se llama wasabi (a mí si me gusta el nombre ). La PC target se llamará tellus. Desde mi notebook me conecto a un router via wifi (el cual me brinda Internet), y a tellus por cable. La interfaz de la primer conexión es wlan0, y la de la segunda eth0.

Procedimiento

wasabi

• En wasabi solamente es necesario tener dnsmasq instalado (hará de servidor DHCP y además tiene un server TFTP incluido).
• La IP de wasabi será 192.168.0.1
• Editamos las opciones en /etc/dnsmasq.conf. Agregamos las siguientes lineas (asegúrense de que el archivo no tenga otras opciones conflictivas activadas):

listen-address=192.168.0.1
interface=eth0

dhcp-no-override
dhcp-range=192.168.0.30,192.168.0.60,12h

dhcp-boot=pxelinux.0
enable-tftp
tftp-root=/var/ftpd

• Coloquen el CD de Ubuntu Server (o la versión que sea) en su lectora, y copien los archivos necesarios para realizar la instalación por red:

$ sudo cp -ar /media/cdrom0/install/netboot/* /var/ftpd

• Otra opción al paso anterior es bajarse los archivos desde Internet, para Intrepid o para Jaunty por ejemplo.
• # sudo service dnsmasq restart
• En este punto ya tenemos andando dnsmasq, como servidor DHCP, DNS y TFTP.
• Activamos IP Masquerading:

# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE

• Como les dije, tellus no puede bootear directamente por red, así que es necesario crear un disquette con gPXE. Tienen que elegir el modelo de placa de red exacto de la máquina target (tellus en este caso) para poder bootear, traer la imagen desde wasabi y arrancar la instalación. Una vez bajada, pueden grabarla en un disquette (que difícil conseguir un disquette estos días… y uno que ande) con dd en GNU/Linux o rawwritewin en Windows.

tellus

• Colocan el disquette creado y bootean desde él. Deberían ver cómo la máquina target pide una IP y arranca el instalador de Ubuntu.

Listo, eso es todo. Un inconveniente que tuve fue resuelto con la opción “dhcp-no-override” que les mostré arriba, para dnsmasq. Resulta que en modo normal no arma paquetes DHCP del todo estándar, y que hacían tellus no pueda encontrar la opción de “archivo de booteo” al recibir el paquete DHCP.

miltondp@wasabi:~$ csharp
Mono C# Shell, type "help;" for help

Enter statements below.
csharp> using System.Text;
csharp> var a = new StringBuilder("Milton");
csharp> a.Remove(a.Length-1,1);
Milto
csharp> a.Remove(a.Length-1,1);
Milt
csharp> a.Remove(a.Length-1,1);
Mil
csharp> a.Remove(a.Length-1,1);
Mi
csharp> a.Remove(a.Length-1,1);
M
csharp> a.Remove(a.Length-1,1); 

csharp>

Si, funcionaba como me lo imaginaba Esta shell para C# está disponible en la versión 2.2 de Mono.

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.