La evolución del control de versiones, tercera parte: Mercurial

Estoy escribiendo una serie de artículos para mostrar los nuevos Sistemas de Control de Versiones (SCV). Esta es el tercero en la serie y los demás están aquí:

• Parte 1: Introducción
• Parte 2: Distribuido vs. Centralizado

Comenzando con Mercurial

Mercurial esta hecho totalmente en Python. Se puede bajar de http://mercurial.selenic.com/

Si se usa Windows, lo mejor es bajar TortoiseHG, que hace las veces de cliente y servidor de Mercurial. Es una extensión del shell de Windows (como TortoiseSVN) que pone todo el control de versiones en el menú de clic-derecho del explorador de archivos.

Por supuesto, existen plugins para los ambientes principales de desarrollo con la excepción de Delphi desgraciadamente (habrá que escribir uno ;-)

Para Visual Studio, pueden usar VisualHG, que de todos modos requiere y depende de que tengan instalado TortoiseHG. Para Eclipse la opción se llama extrañamente Mercurial Eclipse.

Mi repositorio

Con Mercurial lo mas importante es que tenemos un repositorio en la misma carpeta que tenemos nuestra copia de trabajo. Dentro de nuestra carpeta de proyecto tendremos una carpeta llamada .hg en donde esta todo el soporte de control de versiones, y nuestro propio repositorio.

Guía rápida a mercurial

Esta es una guía de conceptos/comandos para el uso de Mercurial:

Concepto	Descripción
Init	Crea un repositorio nuevo, con su respectiva copia de trabajo. Ejecutamos Init sobre la carpeta en donde tenemos nuestro proyecto y se genera una carpeta .hg donde esta nuestro repositorio, y la carpeta se convierte en una copia de trabajo.
Add	Marca los archivos de la copia de trabajo que no están versionados como listos para ser controlados. Se “copiaran” al repositorio en el siguiente commit.
Commit	Toma todos los cambios en la copia de trabajo y los copia al repositorio. Los cambios pueden ser: nuevos archivos, modificaciones en los archivos, borrado de archivos, nuevas configuraciones del repositorio (archivos ignorados, conexión a dependencias, etc.) Un conjunto de cambios se le llama changeset, y debe de ir acompañado de un mensaje, que en un mundo bueno debemos usar para describir que incluyen nuestros cambios.
Revert	Regresar los archivos al estado en que estaban cuando hicimos el ultimo commit, como quien dice, tirando a la basura nuestros últimos cambios. Esto sirve cuando la regamos y no hay forma mas sencilla de arreglarlo.
Log	Obtenemos una bitácora de changesets que incluye: fecha del commit, usuario que lo realizo, mensaje descriptivo que incluimos en el commit, listado de archivos modificados, añadidos, borrados, etc.
Push	Subimos nuestros cambios a un repositorio ligado al nuestro, por ejemplo, un repositorio común. Lo que se sube al repositorio son los changeset que dicho repositorio no tenga, en el orden cronologico. Esto no sube cambios de nuestra copia de trabajo, para eso es el commit.
Pull	Bajamos de un repositorio ligado hacia nuestro repositorio, los changesets hechos por otros desarrolladores o subidos desde otros repositorios. Pull solo actualiza nuestro repositorio local, no nuestra copia de trabajo. Para eso, usamos update.
Update	Actualiza nuestra copia de trabajo, aplicando changesets que tenemos en nuestro repositorio local. Podemos ”actualizar” los archivos de nuestra copia a cualquier changeset que queramos.
Status	Lista los cambios en nuestra copia de trabajo.
Clone	Crea un repositorio clon, o ligado, a partir de otro repositorio Mercurial.
Heads	Una “punta” es el ultimo changeset en un repositorio. Podemos tener mas una punta ¿Como!? Fácil. -> Juanito y Maruja actualizan su código hasta el changeset 5 -> Luego cada uno hace diferentes cambios y hacen un commit. Los dos tendrán un changeset 6 en su repositorio local. -> Después Juanito sube su changeset al repositorio central. -> En seguida, Maruja baja los últimos cambios antes de subir los suyos y se da cuenta que Juanito ya subió otros. -> Cuando maruja haga commit, su repositorio local tiene dos “puntas” o heads: el changeset 6 de Juanito, mas el changeset 7, con sus cambios. Para poder subir sus cambios, Maruja tendría que hacer algo, por ejemplo Mezclar (Merge) las dos puntas.
Merge	Mezcla los cambios de dos “puntas” del repositorio. Lo que hace Mercurial, usa algoritmos para identificar que líneas se modificaron en uno y en otro, mezclando efectivamente un archivo con todos los cambios. En caso de un conflicto en donde se hayan editado la misma sección o líneas de un archivo por parte de ambos changesets, se podría abrir una utilería de sincronización que nos ayudara a editar el archivo resultante de forma interactiva, comparando todos los cambios.

Espero esta guía sea de utilidad para comenzar con Mercurial.

A la Apple

Mercurial y Git son dos sistemas de control de versiones distribuidos(SCVD) y entres si son prácticamente hermanos gemelos.

Ambos proyectos open source y gratuitos nacieron de hecho casi al mismo tiempo y por las mismas causas. Pero como todos los gemelos, se parecen tanto que sus diferencias se ven mucho mas grandes cada vez.

Digámoslo así: Si comparamos los SCV con sistemas operativos, Subversion es Windows 98, Mercurial es Mac OS X y Git es Linux (la distribución que se les antoje).

Depende de lo que se trate, uno u otro tiene ventajas sutiles sobre el otro.

Hay diversos detalles adicionales que tomar en cuenta, por ejemplo, configurar nuestros proyectos para ignorar ciertos archivos inútiles o temporales, que de otra manera, estarían haciendo conflictos innecesarios.

Cuando me sea posible, expondré algunos detalles adicionales, además de mostrar las diferencias de uso con Git.

Por cierto! aprovecho este post para promocionar los nuevos cursos de Silverlight y Delphi que tenemos programados en Metacode para Enero y Febrero 2011. Si no tenemos programados algunos, pidan información con toda confianza ;-)