One sad point, as he’s a person I certainly admire for his work on free software, is that, while praising the way git faces that problem, he unfairly bashes Mercurial (besides other VCSs). The fact is that the comparison done is not correct. While the comparison used to measure store size is between packed git and standard Mercurial, the robustness of the repository format comparison uses the unpacked git and standard Mercurial.

I believe this is more of a handwaving issue than any real concern about how git or Mercurial are doing the job.

Mercurial uses a compact representation of data with separate revlog files for each tracked file, manifest and changelog, which are all append-only. Due to the append-only nature of those writes, the changes in each new revision don’t affect previous revisions. You are that way as safe as you can be in any other system with respect to writes and the space usage is very good.

To achieve similar space efficiency git needs to pack the repository data. This is done rewriting the repo, and the operation has to be done from time to time (repack).

IF the atomic append-only writes to the manifest and revlog files in Mercurial can be considered dangerous, then repacking is even more so, as it forces a rewrite of all the repo data, multiplying the chance of a failure.

So, if any corruption can happen on a faulty write it will hit git (unpacked) or Mercurial in the same way, but anytime you pack your repo in git you’re risking your data and the write fails you can corrupt its repository.

That said, one can meditate whether this unlikely situation of failure is of so high importance, as, in distributed systems, a lot of other repos will act as a full backup of the canonical repo. Furthermore, both use atomical operations and safety should be more than good enough.

A short reply to Keith’s post has been written by Matt Mackal, Mercurial‘s main author, and detailed information about the repository format and other design details for Mercurial can be found on the project’s wiki.

Esta tercera parte de la serie de artículos sobre el control de versiones en proyectos de software está enfocada a la configuración del acceso y publicación de repositorios de Mercurial usando servidores HTTP o SSH.

El traspaso de información entre distintos desarrolladores dispersos en la red es uno de los casos de uso en los que se aprecia con mayor claridad la potencia de los sistemas de control de versiones distribuidos.

En la primera parte se puede leer una introducción a los conceptos fundamentales utilizados en los sistemas de control de versiones y Mercurial, mientras que la segunda parte entra de lleno en el uso de Mercurial para gestionar un proyecto de software.

Publicación de repositorios

Para el trabajo en grupos distribuidos resulta fundamental la publicación de los diversos repositorios de trabajo de un proyecto. Es posible usar un servidor (o varios) en los que se agregan los repositorios públicos y el uso de servidores web o que usen el protocolo SSH es una de las formas más sencillas de hacerlo.
Una de las cuestiones que surgen al publicar uno o más repositorios es el de los permisos que tienen los distintos usuarios en cuanto a la lectura o modificación de los repositorios. Mercurial delega en el sistema operativo el control de los permisos sobre los repostorios, por lo que la forma más natural de organizarlos es mediante la separación de privilegios por usuario. En esa situación, el problema se convierte entonces en el de la autentificación de los usuarios entrantes.

En este artículo se explican todos estos conceptos y cómo proporcionar acceso universal de lectura a los repositorios mediante el protocolo HTTP, y acceso de lectura o lectura y escritura mediante el protocolo SSH, usando autentificación por clave pública.

Acceso de serie con el protocolo HTTP

HTTP es el protocolo de comunicación que usan los servidores de la web, y es uno de los mejor soportados tanto en los servicios de alojamiento como por la infraestructura de la red (proxies). Mercurial incluye de serie un servidor de repositorios que usa como protocolo de comunicación HTTP.

El servidor incluido por defecto en Mercurial es especialmente útil para compartir un repositorio a través de la red de forma rápida y sencilla, sin necesidad de instalar ningún software adicional. Para poner en marcha ese servicio, simplemente basta con utilizar el siguiente comando mientras nos situamos dentro del directorio de trabajo del repostorio que queremos compartir:

$ hg serve

Una vez arrancado el servidor, es posible acceder al repositorio exportado usando como URL la dirección desde la que se sirve. El servidor integrado usa también por defecto el puerto 8000, para evitar conflictos con un servidor web que se encuentre en la misma máquina, pero es posible modificar el puerto usado utilizando la opción -p puerto.

Si, en una red local, nuestra máquina tuviese la dirección IP 192.168.0.10, podríamos acceder desde cualquier máquina de la red al proyecto para, por ejemplo, clonarlo así:

$ hg clone http://192.168.0.10:8000 copia-local

Integración con un servidor HTTP dedicado (Apache)

Si se pretende dar acceso de forma continuada a un conjunto de repositorios es preferible el uso de un servidor web dedicado tal como Apache.
La forma de integrar Mercurial con el servidor HTTP es a través de una aplicación CGI especializada que se distribuye con la aplicación principal.

A continuación se explica la configuración de esta modalidad para compartir repositorios utilizando un servidor Apache, basándose en la experiencia del autor en la configuración de este servicio en un servidor compartido en una máquina del proveedor Dreamhost.

Cuenta dedicada

Para limitar los riesgos de seguridad del uso de una aplicación CGI que realiza operaciones de lectura y escritura, es preferible configurar una cuenta de usuario dedicada, diferente a nuestra cuenta habitual. Con esta precaución, en el caso de que la aplicación CGI se viese comprometida por un fallo de seguridad, solamente los datos accesibles por el usuario de la cuenta (preferiblemente sólo los de los repositorios), podrían estar en peligro. La cuenta, por tanto, deberá tener los mínimos privilegios posibles.
En el ejemplo que usaremos en este artículo, el usuario se llamará mercurial.
(Puede ser necesario configurar correctamente la codificación de caracteres con LC_ALL)

Aplicación CGI

En este artículo situaremos la aplicación CGI en el subdirectorio ~/repos

El ejecutable CGI que debemos instalar en ese directorio es hgwebdir.cgi, que se encuentra en la distribución estándar de Mercurial. Este ejecutable es el encargado de realizar la compartición de los repositorios y presenta la interfaz web.

En el archivo cgi existen un par de elementos para personalizar algunas opciones, para el caso en que se quieran mostrar páginas con codificaciones distintas a las predefinidas para el usuario (variable HGENC) y cuando la ruta de instalación de python no sea la general del sistema.

Junto con ese archivo debemos crear un archivo de configuración hgweb.config que servirá para indicar los repositorios compartidos y realizar la traducción entre la URL recibida y el directorio en el servidor. El contenido es el siguiente:

[collections]
./repos = ./repos

En nuestro ejemplo simplemente indicamos que la raíz de los directorios con repositorios se encuentra en el directorio de instalación, pero es posible indicar otras rutas, e incluso indicar rutas específicas por proyecto o por repositorio.
En el lado izquierdo se pone la ruta conocida (o la que se puede omitir en la url).

Control de acceso y reescritura de direcciones

Para realizar el control de acceso, permitir la ejecución de archivos CGI en nuestro directorio y hacer las direcciones de acceso (URLs) más sencillas podemos utilizar los sistemas de configuración estándar de Apache. Bien una configuración global, bien utilizando una configuración por directorio mediante el archivo .htaccess. La primera opción es la más adecuada cuando se tiene acceso a poder modificar la configuración global del servidor, pero aquí explicaremos la última es la opción, puesto que suele estar disponible incluso en servidores de alojamiento compartido, y es sencillo extrapolar la configuración al caso anterior si fuese necesario.

El contenido del archivo ~/repos/.htaccess es el siguiente:

Options +ExecCGI
AddDefaultCharset iso-8859-15
RewriteEngine On
#RewriteBase /
RewriteRule ^$ hgwebdir.cgi [L]
RewriteCond %{REQUEST_URI} !^/hgwebdir.cgi
RewriteRule (.*) /hgwebdir.cgi/$1 [PT]

Esta configuración permite la ejecución de CGIs, reescribe la dirección añadiendo al final hgwebdir.cgi o añadiendo hgwebdir.cgi/directorio/nombre-archivo cuando se solicite un nombre de archivo y un directorio.
De esa manera nuestra aplicación recibirá la ruta que se solicita.

Host virtual

Por comodidad, es conveniente crear un subdominio o host virtual en nuestro dominio principal que esté redirigido hacia la aplicación CGI en la cuenta dedicada. En nuestro ejemplo, la dirección hg.midominio.org podría dirigirnos hacia el directorio repos del usuario mercurial.

Configuración de los repositorios compartidos

Hemos configurado ya el directorio de instalación de la aplicación CGI y hemos decidido que será también el directorio base del árbol de repositorios.
Para cada proyecto tendremos un subdirectorio que contenga los repositorios publicados para dicho proyecto, por ejemplo, para el proyecto “proyecto” y el repositorio “main” tendríamos la siguiente estructura en disco: ~/repos/proyecto/main

Para que los detalles que nos presenta la interfaz web (abriendo en un navegador http://hg.midominio.org/) sean más descriptivos, es recomendable añadir algunos datos en el archivo de configuración de cada repositorio. Este es el archivo ~/repos/proyecto/main/.hg/hgrc y los datos relevantes son:

[web]
contact = Pepito Pérez description = Proyecto - Repositorio principal
name = Proyecto
style = gitweb
allow_archive = gz zip bz2
#allow_push = pachi, coya, ramon

El significado de los distintos campos es bastante obvio, precisando aclaración únicamente:
style: inidica el estilo que se usará en la interfaz web
allow_archive: permite indicar los tipos de archivo que se permiten descargar. Se puede limitar para evitar la sobrecarga del servidor, al exigir cierto trabajo de la CPU.
allow_push: aquí está comentada esta opción, por lo que solamente se permite el acceso para lectura al repositorio publicado por HTTP. La opción allow_push permite incluir un conjunto de usuarios a los que se les permitiría la escritura mediante push al repositorio. La autentificación de los usuarios se podría hacer también mediante la configuración del archivo .htaccess.

En nuestra configuración, evitaremos el acceso mediante contraseñas y daremos acceso de escritura usando autentificación con clave pública, un método mucho más seguro.

Acceso a través de HTTP desde los clientes

Ahora que está configurado el servidor para proporcionar acceso a los repositorios usando el protocolo HTTP es posible realizar cualquier operación (autorizada) desde los clientes simplemente indicando la URL para el protocolo HTTP:

$ hg clone http://hg.midominio.org/proyecto/main proyecto-main-local
$ hg pull http://hg.midominio.org/proyecto/main

Estas órdenes accederían al repositorio ~/repos/proyecto/main del servidor. Hay que cuidar la introducción de la URL de forma correcta, puesto que, gracias a nuestras reglas de reescritura de direcciones no es necesario añadir el directorio repos en la URL.

Acceso de lectura/escritura con clave pública por SSH

El protocolo SSH

SSH es un protocolo de comunicación mucho más seguro que HTTP al incluir la encriptación de los datos, evitando que se puedan interceptar datos privados o sensibles, y, si se combina con la autentificación mediante clave pública se evita también el posible compromiso de las claves de acceso a las cuentas utilizadas.

Una de las ventajas del protocolo SSH es que la mayoría de servidores suelen tener soporte para su uso.

Autentificación con clave pública

A menudo se usa como forma de autentificación en servidores un par usuario/contraseña. En este modo de autentificación un usuario registrado en el sistema se identifica como tal y posteriormente envía su contraseña para asegurar que se trata del usuario legítimo. El problema de esta forma de autentificación es que el envío de la contraseña se produce a través de la red, con lo que una línea no segura puede llevar a comprometer la identidad del usuario.

Existen métodos más modernos de autentificación basados en el intercambio asimétrico de información. Son los llamados sistemas de clave pública. En estos sistemas se utiliza un par de claves, una llamada clave pública y que sirve para identificar la autenticidad y descifrar los mensajes cifrados usando la otra clave, la clave privada.

La clave pública se distribuye y almacena en los servidores que se desea que puedan identificar al poseedor de la clave privada, mientras que la clave privada siempre queda en posesión del usuario que se identifica.
El mecanismo utilizado es el siguiente: una vez iniciada la transmisión, sel servidor solicitar al cliente que desea iniciar una transacción que encripte un mensaje único (de usar y tirar) haciendo uso de su clave privada; luego comprueba que es posible desencriptar el mensaje correctamente usando la clave pública almacenada, y, en ese caso, da acceso al usuario.

La ventaja de este sistema es que en ningún momento se produce un intercambio de contraseñas por la red, quedando la clave privada siempre a salvo de cualquier intento de controlar la comunicación. Es sumamente difícil (prácticamente imposible en un tiempo razonable) generar la clave privada a partir de la clave pública o de ésta y un mensaje conocido encriptado, con lo que el sistema es muy seguro.

Instalación

Para poder utilizar SSH como protocolo de comunicación es necesario, además de un servidor de SSH, la presencia de un cliente que realice las operaciones de comunicación. Uno de los clientes más fiables, que además es software libre, es OpenSSH, y suele estar instalado en cualquier sistema GNU/Linux o BSD. En sistemas Windows es preferible, por más práctico, usar el conjunto de aplicaciones ‘Putty’ (putty.exe y plink.exe), que se puede obtener en http://www.chiark.greenend.org.uk/~sgtatham/putty/.

Generación de pares de claves para controlar el acceso

Uno de los primeros pasos que debemos dar es la generación del par de claves pública y privada. Para ello utilizamos la herramienta ssh-keygen de la siguiente manera:

$ ssh-keygen -t rsa -f hg-identity

La aplicación ssh-keygen devuelve un par de claves hg-identity, hg-identity.pub, que son la clave privada y la clave privada, que usaremos en los clientes y el servidor.

SSH: Configuración del servidor

Instalación de las claves públicas de los usuarios autorizados

Cada usuario guarda una lista de las claves públicas a las que permite el acceso en el archivo ~/.ssh/authorized_keys.
Debemos añadir en nuestra cuenta dedicada en el servidor la lista de usuarios a los que permitiremos el acceso por SSH a los repositorios publicados.

En él se añade una línea por cada clave, y tiene un aspecto similar a este:

ssh-rsa FACeilOTrm2UFa2RAAGTCIxAAAIExRCBsdwYyLFNzaCiShtyr9qp9KJGPRvJExtnuP3td6EApGyLwb0DU2UJfr9xJG+1LUwBwai7m0bqbxwe3CVBc7ysudePiBbg88ZXHw/77z0CQTFNReySVzzaXyjKWeRxGTu+cyoBjEQcUTltj+ncG78xQYcKHfwC5cX6MgU=4Sk3 pepito@perez.org
ssh-rsa DAGTCIxhtyr9yLqaC3td2RasdwYxtAAABApiSnuPFE9KJGPGCNzARv6IEJexREilOTrm2UFpGy3CVBUwai7mDeey2UJfr9xJHw/bwBG+1LUjK77z0CQbg88ZXxwc7ySVzzaTF0bqbsudePiBXy0NRLwWGTu+cyoBjYcKHxSk3cEQgU=cUTltj+ncG78xQX6MfwC54eR paco@perez.org

Vemos que cada línea empieza por el tipo de clave usado (en este caso, ssh-rsa), la clave codificada como cadena alfanumérica, y acaba con un identificador arbitrario (como pepito@perez.org).

Restricción de las operaciones al trabajo con Mercurial

Es posible limitar la capacidad de los usuarios para que únicamente puedan realizar algunas operaciones con Mercurial . Esto facilita la publicacion de repositorios dando acceso a grupos de usuarios no totalmente confiables, sin comprometer la seguridad del sistema.

Para ello, podemos aprovechar la posibilidad de ejecutar una orden cada vez que se usa una clave pública para la autentificación. Esto se consigue insertando la opción command al principio de cada linea con una clave pública en el archivo ~/.ssh/authorized_keys. Lo que haremos en nuestro caso es utilizar un script que filtrará y redirigirá las acciones permitidas al ejecutable de Mercurial.

El script hg-ssh es el que realiza este trabajo, está escrito por Thomas Arendsen Hein y se puede obtener en la distribución estándar de Mercurial, en el directorio contrib. Para simplificar el uso optamos por instalar el script en ~/hg-ssh.
El script usa como parámetros las rutas de los repositorios en los que se permite actuar y dejaría las entradas en el archivo ~/.ssh/authorized_keys así:

command="hg-ssh repo-pepito/ /repos/main ~/crew-repo", ssh-rsa FACeilOTrm2UFa2RAAGTCIxAAAIExRCBsdwYyLFNzaCiShtyr9qp9KJGPRvJExtnuP3td6EApGyLwb0DU2UJfr9xJG+1LUwBwai7m0bqbxwe3CVBc7ysudePiBbg88ZXHw/77z0CQTFNReySVzzaXyjKWeRxGTu+cyoBjEQcUTltj+ncG78xQYcKHfwC5cX6MgU=4Sk3 pepito@perez.org
command="hg-ssh repo-paco/ /repos/main ~/crew-repo", ssh-rsa DAGTCIxhtyr9yLqaC3td2RasdwYxtAAABApiSnuPFE9KJGPGCNzARv6IEJexREilOTrm2UFpGy3CVBUwai7mDeey2UJfr9xJHw/bwBG+1LUjK77z0CQbg88ZXxwc7ySVzzaTF0bqbsudePiBXy0NRLwWGTu+cyoBjYcKHxSk3cEQgU=cUTltj+ncG78xQX6MfwC54eR paco@perez.org

Vemos que es posible utilizar rutas absolutas, relativas, o con expansión del directorio de usuario a la hora de indicar la situación de los repositorios accesibles para cada usuario.

Con esto está ya completa la configuración por el lado del servidor. Ya está configurado el acceso para lectura y la interfaz web, están registrados los usuarios que pueden utilizar los repositorios a través de SSH y configurado el acceso para permitir únicamente operaciones en los repositorios autorizados para cada usuario.

SSH: Configuración de los clientes

Ahora veremos la parte de los clientes, que deben acceder a los repositorios remotos que acabamos de configurar.
Como primer paso debemos indicar a nuestro cliente SSH el lugar donde guardamos nuestra clave privada para que nos identifique correctamente ante el servidor que hemos configurado. La configuración puede variar algo según la realicemos en sistemas GNU/Linux o BSD, o en sistemas Windows. Los primeros admiten cualquiera de las dos formas de configuración, aunque parece más limpia la primera que se indica.

Sistemas GNU/Linux y BSD (o windows con MSYS)

En sistemas GNU/Linux o BSD podemos configurar el usuario y la clave privada para el acceso por SSH a cada dominio. Esta configuración se lleva a cabo en el archivo ~/.ssh/config:

Host hg.midominio.org
    user hguser
    IdentityFile ~/.ssh/hguser-identity

El Host hg.midominio.org identifica el dominio para el que son de aplicación las siguientes opciones. El usuario por defecto se indica tras la opción user, y la clave privada del archivo indicado tras la opción IdentityFile.

Win32

En sistemas Windows (en GNU/Linux se podría hacer igual) no es posible usar la configuración global anterior y por ello se debe recurrir a modificar la configuración de Mercurial. El archivo de configuración para cada usuario, Mercurial.ini (~/.hgrc en sistemas *nix), permite indicar la orden que se ejecuta para realizar la conexión por SSH:

[ui]
ssh=/path/a/plink.exe -ssh -i "c:\ruta\a\hg-identity" -l mercurial

En este ejemplo se usa plink.exe, que es el cliente de SSH para Windows (ssh en *nix), y como opciones se indica -ssh para que use el protocolo ssh en la conexión, -i “/ruta/a/hg-identity” para indicar la ruta del la clave privada para identificarnos en la conexión, y -l mercurial para acceder al servidor a través del usuario mercurial (el usuario de nuestra cuenta dedicada).

Primera conexión

En ambos sistemas, para terminar de realizar la configuración, es necesario conectarse manualmente por primera vez a la máquina remota para que su clave pública sea añadida a las claves públicas reconocidas por nuestra máquina (también podemos haberla añadido manualmente con anterioridad). Esto se realiza con la siguiente orden:

$ ssh hg.midominio.org -i ruta/a/hguser-identity -l mercurial

o

> plink.exe -ssh -i "/ruta/a/hg-identity" -l mercurial

Trabajo con los repositorios

Para clonar un repositorio existente o traer cambios simplemente usamos las órdenes habituales de mercurial, indicando en la URL que el protocolo de comunicación es SSH:

$ hg clone ssh://hg.midominio.org/repos/proyecto/main proyecto-main-local
$ hg pull ssg://hg.midominio.org/repos/proyecto/main

Hay que resaltar que, en este caso, y a diferencia del acceso con HTTP, es preciso indicar la ruta completa a los repositorios (incluyendo repos) desde el directorio raíz del usuario dedicado de nuestro servidor, puesto que es ahí donde se inicia el acceso por SSH.

NOTA:
Si hay conflictos de usuario y no se envía correctamente el nombre de éste puede ser necesario añadir el usuario antes de la máquina:

$ hg clone ssh://mercurial@hg.midominio.org/repos/proyecto/main proyecto-main-local
hg pull ssh://mercurial@hg.midominio.org/repos/proyecto/main

Pendiente: Cambiar “repos” por “mercurial” e igualar la sintaxis del acceso por HTTP y SSH (Modificando RewriteRule o hgweb.config)

NOTA:
En pascaline usamos los siguientes repositorios:

$ hg clone ssh://hg.rvburke.com/repos/pascaline/main pascaline-main
hg clone ssh://hg.rvburke.com/repos/pascaline/pachi pascaline-pachi
hg clone ssh://hg.rvburke.com/repos/pascaline/pascaline-crew pascaline-crew
hg clone ssh://hg.rvburke.com/repos/pascaline/ramon pascaline-ramon
hg clone ssh://hg.rvburke.com/repos/pascaline/coya pascaline-coya

Enlaces interesantes

Página con trucos sobre la instalación y uso de Mercurial y MQ.

Esta es la segunda parte de una serie de artículos introductorios al uso de sistemas de control de versiones.
En la primera parte se explican los conceptos generales necesarios para comprender el funcionamiento y la forma de trabajo de un sistema de control de versiones. En esta segunda parte se explica el uso particular de Mercurial, de forma que sea posible realizar con esta herramienta la gestión del código de un proyecto de software.

Mercurial

Mercurial es una aplicación para el control de versiones publicada bajo una licencia libre (GPL). Sus principales características son el carácter distribuido y la gran velocidad de funcionamiento.

La página principal del proyecto contiene abundante información (en inglés) sobre su uso, trucos, además de versiones del programa para su instalación.

Instalación de Mercurial

Existen paquetes binarios para la instalación de Mercurial, tanto para GNU/Linux como para Windows, y esa es la forma recomendada para su instalación.

El instalador de Mercurial para win32 tiene, a 5 de septiembre de 2006, su versión 0.9.1.

Es posible también hacer una instalación desde el código fuente usando:

#python setup.py install

Además del intérprete de python es necesaria la presencia de un compilador de C (gcc) para compilar las extensiones hechas en ese lenguaje.

Es posible comprobar si Mercurial está correctamente instalado en el sistema llamando a la aplicación desde la línea de comandos y comprobando que devuelve información sobre la versión instalada:

$ hg

Mercurial Distributed SCM (version 0.9.1)

Copyright (C) 2005 Matt Mackall
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Personalización del programa

Archivos de configuración

Las personalizaciones para todo el sistema se hacen en ~/.hgrc, o en ~/Mercurial.ini si trabajamos en windows, aunque es posible personalizar el funcionamiento de Mercurial para cada repositorio usando en archivo .hgrc en el directorio de trabajo.

Usuario, editor y nivel de información

Cada envío de cambios al repositorio de un proyecto almacena datos sobre el usuario que realiza el cambio. Para que esa información sea correcta es necesario proporcionar esa información mediante una opción en la línea de comandos (-u username), o, más cómodamente, aportándola en el archivo de configuración, en el apartado username del bloque [ui].

Otro de los datos que se incluye en los cambios es un mensaje que explica el cometido de los cambios. Ese texto se puede aportar en la línea de comandos con la opción -m mensaje, o utilizando un editor para escribir el comentario. El editor que abrirá Mercurial para introducir el texto se configura en el apartado editor del bloque [ui] del archivo de configuración.

Una opción global interesante, para que Mercurial sea un poco más locuaz en su operación, es -v, que puede seleccionarse por defecto en el archivo de configuración mediante el apartado verbose del bloque [ui].


[ui]
# editor por defecto (gvim o el que sea):
editor = gvim
# pedir indicación de archivos cambiados:
verbose=True

# usuario que se usa al indicar quién hace los cambios:
username="Pepito Pérez <pepito@perez.org>"


Reconciliación de cambios

Cuando se desean combinar las distintas versiones de un archivo (merge) es posible utilizar programas que facilitan la reconciliación de los cambios que existen entre ellas. Mercurial hace uso de aplicaciones externas para este cometido, que son habituales en sistemas Unix, pero que han de instalarse separadamente en sistemas Windows. A continuación describimos la configuración e instalación del programa kdiff3 para la reconciliación de cambios en windows:

Kdiff3 dispone de un instalador de su versión 0.9.90 para windows.

Para localizar los cambios entre una versión base (base) y dos versiones que queremos combinar (local, other), Kdiff3 recibe los datos en un órden (base, local, other) distinto al de Mercurial (local, base, other), por lo que es necesario escribir un pequeño script que se encargue de reordenar la información que Mercurial pasa a Kdiff3. Este script, llamado hgmerge.cmd debe tener el siguiente contenido:

...\path\to\kdiff3.exe --auto -L1 Base -L2 Local -L3 Other %2 %1 %3 -o %1

En http://www.selenic.com/mercurial/wiki/index.cgi/MergeProgram se proporciona más información sobre la reconciliación de cambios en Mercurial.

Uso de SSH como protocolo de comunicación

Mercurial usa HTTP como protocolo nativo de comunicación, aunque es posible usar SSH si tenemos un cliente de ssh instalado, tal como OpenSSH y, en algún caso, se personaliza la configuración de Mercurial. Esta configuración se explica en la tercera parte de esta serie de artículos sobre Mercurial. En ésta se explica además cómo acceder a un repositorio remoto usando ssh y claves públicas en lugar de contraseñas.

NOTA: Todas las aplicaciones externas de las que hace uso Mercurial, tal como ssh, vim o kdiff3, deben estar en la ruta por defecto (PATH) del usuario o del sistema para que Mercurial pueda localizarlas

Uso de Mercurial

Antes de explicar más detalles, es necesario señalar que Mercurial tiene su propio sistema de ayuda que nos será de utilidad a la hora de conocer los detalles de cada comando y para localizar el comando adecuado a nuestras necesidades.

En el wiki del proyecto se puede consultar la lista de preguntas frecuentes además de otras informaciones detalladas de instalación, configuración, etc… En sistemas Unix/Linux es posible también usar las páginas del manual.
Las opciones generales y una lista de órdenes básicas se pueden consultar con:

$ hg help

Para obtener ayuda sobre una orden en particular:

$ hg help orden

Creación de un repositorio

La creación de un repositorio de Mercurial consiste en la creación de un directorio con algunos metadatos. La orden init es la responsable de crear los metadatos y el directorio de trabajo:

$ hg init nombre-repositorio

Si se omite el nombre del repositorio, se puede convertir el directorio actual en un repositorio de Mercurial:

$ hg init

Incorporación de archivos al repositorio para rastrear sus cambios

Para que Mercurial rastree los cambios en un archivo que se encuentra en el directorio de trabajo es necesario incorporarlo al repositorio. Para ello se usa la orden add, con el nombre de los archivos como parámetros.

$ hg add nombrearchivo1 nombrearchivo2 ...

Estado del directorio de trabajo

Es posible conocer el estado de los archivos del directorio de trabajo en relación a su seguimiento por Mercurial utilizando la orden status.

$ hg status
? c.txt
M a.txt

La orden status devuelve una lista de archivos precedidos por un caracter indicador de estado. Los más importantes son:

• M – el archivo contiene modificaciones que no se han registrado en el repositorio
• A – el archivo está marcado para ser añadido al repositorio en el siguiente envío de cambios o “commit”
• ? – el archivo no está siendo seguido por Mercurial

Envío de cambios al repositorio

Cuando se realizan modificaciones en los archivos seguidos por Mercurial es posible guardar ese conjunto de cambios (changeset) en el repositorio local utilizando la orden commit.

$ hg commit

Esta orden abre una sesión en el editor de textos que se haya configurado para la introducción de un texto que sirva de aclaración a los cambios guardados. Es posible indicar una cadena de texto en la línea de comandos para su uso en el registro de cambios, sin necesidad de utilizar el editor, y también inidicar un usuario como responsable de los cambios:

$ hg commit -u 'Pepito Pérez <pepito@perez.org>' -m "El propósito de los cambios es blah blah"

Bitácora de cambios

Se puede ver una lista de los conjuntos de cambios que se han ido haciendo a lo largo de la historia de un proyecto.

"$ hg log"
changeset: 2:f27f5477492b1d40d138e087485877659427c23b
tag: v1.0
user: Paco Pérez <pepito@perez.org>
date: Tue Jun 13 22:55:24 2006 +0200
files: a.txt b.txt
description:
El propósito de los cambios es blah blah

changeset: 1:797bf3bff932f8c36c9be4ec323f88fb524239ec
user: Paco Pérez <pepito@perez.org>
date: Tue Jun 13 22:30:52 2006 +0200
files: a.txt
description:
Modificar a.txt

changeset: 0:cb3e6e73d53bab2462e38cedc6fa68eef4e70217
user: “Usuario de prueba <prueba@cielito.sindominio.net>”
date: Tue Jun 13 22:25:17 2006 +0200
files: a.txt b.txt
description:
Guardamos versiones iniciales de los archivos a.txt y b.txt.

En la bitácora de cambios podemos ver los metadatos asociados a cada changeset:

• changeset: Identificación del conjunto de cambios mediante: ‘número de revisión:changeset ID’. El número de revisión proporciona una referencia válida solamente para cada copia del repositorio, mientras que el changeset ID constituye una referencia absoluta, incluso entre copias en distintas máquinas.
• user: identificación del usuario bajo el que se registra el conjunto de cambios
• date: fecha, hora y zona horaria en la que se registró el conjunto de cambios
• files: archivos implicados en el conjunto de cambios
• description: texto descriptivo de los cambios

Tras esta serie de conjuntos de cambios la historia del proyecto sería algo similar a:

y el dirstate, o changeset padre del directorio de trabajo se encuentra en la revisión 2, la señalada en rojo en el diagrama.

Recuperación de revisiones

Podemos recuperar el estado del directorio tal como estaba tras una revisión determinada. Esta operación, llamada actualización del repositorio, permite recorrer la historia del proyecto y resulta útil para poder ver el estado de los distintos archivos en una revisión determinada, ver los cambios hechos tras importar algunos cambios desde un repositorio externo, o para situarse en un punto diferente del proyecto para crear una nueva rama a partir de él.

La orden que nos permite realizar la actualización de un repositorio es update.

$ hg update revision

Update toma como parámetro revisión el changeset al que se desea actualizar. Es posible indicar dicho changeset mediante el número de revisión, un ‘tag’, o con el changeset ID. Mercurial es capaz de reconocer un changeset ID si se le pasa una parte inequívoca de la cadena alfanumérica que lo define, sin necesidad de indicar la cadena completa.

En el ejemplo anterior, si realizamos las siguientes operaciones:

$ hg update 797b

ó

$ hg update 1

cambiaríamos la revisión que se visualiza en el directorio de trabajo a la revisión 1:797bf3bff932f8c36c9be4ec323f88fb524239ec. En la historia del proyecto, nos situaríamos en el estado del proyecto tras el envío del segundo conjunto de cambios:

Si se omite el parámetro de revisión en la orden update, entonces se presupone la revisión ‘tip’ (el último conjunto de cambios guardado).

En nuestro ejemplo,

$ hg update

nos llevaría de nuevo a la última revisión del proyecto:

Visualización de diferencias entre revisiones

Se pueden ver las diferencias entre dos versiones:

$ hg diff -r version1 -r versión2

ó

$ hg diff -r version1:version2

, entre una versión y la versión del directorio de trabajo:

$ hg -r version1

, o entre el changeset padre del directorio de trabajo y los cambios en el directorio de trabajo:

$ hg diff

Las versiones, como en el resto de órdenes de Mercurial, se pueden indicar con el número de revisión, el Changeset ID o un tag.

Copia de repositorios y ramas (branches)

Se puede clonar un repositorio, de manera que sea posible recuperar datos de su “original” para integrar los cambios en uno u otro sentido. La orden clone es la usada para este cometido.
Esta operación es muy habitual, puesto que permite la creación de repositorios para realizar desarrollos paralelos que pueden integrarse posteriormente en el repositorio original, trasladar cambios entre uno u otro, o mantener permanentemente versiones con cometidos diferenciados. Una forma de uso frecuente es el desarrollo de funcionalidades en ramas separadas, para integrarlas en el repositorio principal una vez que la implementación de los cambios ha madurado.

La orden

$ hg clone repositorio-original repositorio-copiado

clona el repositorio ‘repositorio-original‘, haciendo una copia llamada ‘repositorio-copiado‘.

La historia de ambos proyectos se mantiene igual,

y, además, el repositorio copiado guarda la ruta al repositorio original (default path o ruta por defecto). Enn algunas operaciones de traslado de información entre repositorios, si se omite la ruta de trabajo, se utiliza la ruta por defecto. En el siguiente apartado se presentan algunas órdenes donde esta funcionalidad resulta cómoda.

NOTA: Para diferenciar dos repositorios relacionados en nuestros ejemplos diferenciaremos sus números de revisión mediante un apóstrofe. Hemos de recordar que estos números de revisión son propios de cada repositorio, ya que simplemente indican el orden en el que se almacenó un changeset en la historia de ese repositorio. Sin embargo, dos changeset idénticos (de idéntica historia y contenidos) tienen el mismo changeset ID, aunque difieran en sus números de revisión.

Traslado de información entre repositorios (push y pull)

Se pueden trasladar las modificaciones entre repositorios mediante las órdenes push y pull.
Push integra en un repositorio remoto los conjuntos de cambios del repositorio actual que no se encuentren en él, mientras que pull realiza la operación inversa, integra en el repositorio local los cambios adicionales que contenga el repositorio remoto.
En ambas operaciones es neceario indicar la dirección o URL de destino (push) u origen (pull) de la operación.

$ hg push repositorio-destino

ó

$ hg pull repositorio-origen

Es preciso advertir que estas operaciones simplemente trasladan los cambios entre repositorios, pero no alteran el estado del directorio de trabajo. Si se actualizar el directorio de trabajo al último changeset es probable que se quiera hacer después traer cambios de otro repositorio:

$ hg update

que actualiza a tip.

En nuestros repositorios de ejemplo, si se hubiesen guardado cambios distintos en cada uno de ellos, tendríamos unos nuevos changeset 3′ y 3, el dirstate de cada uno de los repositorios se correspondería a estos nuevos changeset, y la historia de ambos repositorios quedaría así:

Se puede apreciar cómo las tres primeras revisiones comparten su changeset ID (abreviado en el dibujo por comodidad), puesto que son conjuntos de cambios idénticos, mientras que el nuevo changeset de cada repositorio, a pesar de compartir el mismo número de revisión (3), tiene un changeset ID diferente. Esto se debe a que no son cambios idénticos.

Si trabajamos desde el repositorio B, cuyo default path apunta al repositorio desde el que fue clonado (el A), podemos traer los cambios de A hasta B simplemente usando la orden pull, y aprovechando el default path. También es posible trabajar desde A y llevar los cambios a B con la orden push e indicando la ruta a B (puesto que A no tiene un default path que apunte a B):

$ hg pull

ó

$ hg push /ruta/a/repoB

El gráfico que representa la historia de ambos proyectos quedaría así:

En el diagrama se observa que el conjunto de cambios 3′:e48f de A se traslada a B como el changeset de número de revisión 4, manteniendo su changeset ID e48f….

Como consecuencia de la operación que hemos realizado aparece una nueva cabeza de desarrollo en el repositorio B, coincidente con el changeset 4, al compartir las revisiones 3 y 4 el mismo padre 2.

Otro resultado es que la marca tip en B pasa a referenciar al changeset 4, mientras que el dirstate en B no se modifica (representado en rojo). Es decir, no se aprecian cambios en el directorio de trabajo, mientras que la revisión tip, que antes coincidía con el número de revisión 3, pasa ahora al changeset con número de revisión 4, que es el añadido en último lugar.

Si deseásemos cambiar a la nueva cabeza, podríamos hacer simplemente:

$ hg update

ó

$ hg update 4

ó

$ hg update e48f

La primera opción nos actualiza a tip, mientras que en las dos siguientes se especifica explícitamente la revisión o el changeset ID. El resultado final es que el repositorio queda en el siguiente estado:

y que haría que viésemos en el directorio de trabajo el estado del proyecto tal como se encuentra en la nueva revisión 4 del repositorio B (o la 3′ del repositorio A).

Visualización de las distintas cabezas de un proyecto

Cuando integramos los cambios de distintos repositorios mediante push o pull, hemos visto que es probable que se produzcan desarrollos paralelos que den lugar a distintas ramas de desarrollo en el proyecto.

Para localizar las distintas cabezas existentes en el repositorio utilizamos la orden heads:

$ hg heads
changeset: 3:c22f5477492b1d40d138e087485877659427c23b
tag: v1.0
user: Paco Pérez <pacoperez@susitio.com>
date: Tue Jun 23 22:55:24 2006 +0200
files: a.txt b.txt
description:
Cambios preparados en el repositorio B para…

changeset: 4:348ff3bff932f8c36c9be4ec323f88fb624239ec
user: Paco Pérez <pacoperez@susitio.com>
date: Tue Jun 23 22:36:52 2006 +0200
files: a.txt
description:
Cambios preparados en el repositorio A para…

, que nos muestra los changeset que son cabeza de una rama, y refleja las dos cabezas de nuestro ejemplo. En él acabábamos con dos cabezas (números de revisión 3 y 4) tras traer algunos cambios del repositorio A al repositorio B, por haberse producido desarrollos paralelos en ellos:

Los changeset 3 y 4 definen dos ramas de desarrollo en el repositorio que se bifurcan en el changeset 2.

Integración de ramas divergentes (merging)

A menudo no se pretende que las ramas que se producen en un proyecto permanezcan como desarrollos paralelos de forma indefinida. Para reintegrar los cambios de una rama en otra rama es preciso realizar los siguientes pasos:

• Indicar la revisión que se desea integrar con el directorio de trabajo mediante la orden merge.
• Reconciliar los cambios entre las ramas haciendo los cambios necesarios (normalmente con la ayuda de un programa al efecto, por ejemplo, kdiff3, o con nuestro editor preferido).
• Guardar el resultado con una operación de commit, en un nuevo cambio llamado merge changeset o changeset de mezcla.

La orden merge requiere como parámetro el changeset que define la revisión que queremos integrar en la rama actual del directorio de trabajo.

En nuestro ejemplo, para integrar (o mezclar) la rama con número de revisión 3 en la rama de nuestro directorio de trabajo (la 4, ya que la última vez cambiamos el dirstate a la revisión 4 mediante una operación de update) debemos realizar los siguientes pasos:

Indicamos que queremos mezclar la rama 3:

$ hg merge 3

Hacemos los cambios necesarios para reconciliar los cambios al código en ambas ramas…

y hacemos un commit de mezcla:

$ hg commit -m "Merge desde la rama 3"

Tras la mezcla solamente nos resta una cabeza, la correspondiente al changeset de mezcla, el 5, y que habrá de reflejarse en la salida de la orden heads:

$ hg heads
changeset: 5:676bf3bff932f8c36c9be4ec323f88fb624239ec
user: Paco Pérez <pacoperez@susitio.com>
date: Mon Jun 29 12:16:52 2006 +0200
files: a.txt b.txt
description:
Merge desde la rama 3

La etapa intermedia de reconciliación de cambios solamente puede automatizarse parcialmente. Mercurial lanza una aplicación auxiliar para facilitar ese trabajo. La aplicación utilizada es configurable, auque se recomienda el uso de kdiff3, meld o vimdiff.
De todos modos, siempre se deben supervisar los cambios hechos, puesto que el significado preciso de la integración de dos ramas es una cuestión semántica que no siempre puede coincidir con la mezcla por comparación que realizan estas herramientas. Estas permiten, sin embargo, localizar las secciones de código que entran en conflicto (por modificar las mismas zonas del proyecto) y precisan de edición manual, y además realizan una mezcla automática en las secciones en las que no se producen conflictos entre las dos revisiones implicadas, haciendo uso de la información adicional que supone saber cuál es su ancestro común (el changeset en donde se produce la ramificación).

Organización de los repositorios

Una manera bastante práctica para organizar los repositorios de un proyecto es la siguiente:

En esta organización podemos observar los siguientes elementos:

• Un repositorio personal para cada desarrollador en el que cada uno sube su versión “pública” del proyecto. En el diagrama inferior se identifican como repositorios A, B, C o D. Fundamentalmente sirve como backup del trabajo personal y también para que los demás puedan ver los cambios sobre los que está trabajando cada uno. Desde él se suben (push) los cambios al repositorio de integración, al tiempo que sigue los cambios en el repositorio de integración (con pull) para realizar mezclas limpias.
• Un repositorio de integración de cambios (crew) al que se llevan los cambios propuestos por los desarrolladores para la versión estable y desde el que se suben (push) los cambios al repositorio principal.
• El repositorio principal, “canónico” (main), que sirve de referencia pública del proyecto. Recoge los cambios “contrastados” del repositorio de integración.

Los repositorios en las partes superiores del diagrama toman como referencia los repositorios en las zonas inferiores, y van integrando los cambios que se producen en ellos mediante operaciones pull. De esa manera, el código está cada vez más auditado a medida que se avanza en el proceso.

Estos repositorios se encuentran publicados en un servidor (o varios), pero lo más habitual es que los denominados repositorios personales sean a su vez repositorios de integración de otros repositorios locales en los que se hace el desarrollo efectivo. Así, cada desarrollador trabaja en sus repositorios locales sobre nuevas funcionalidades, corrección de errores, etc, y va actualizando (push) los cambios consolidados a su repositorio público de usuario.

Cuando una nueva funcionalidad del repositorio público personal está lista para formar parte de la siguiente versión estable se pasa (push) desde cada uno de los repositorios personales al repositorio de integración (crew), donde se va probando, y pasa a ser la base sobre la que trabajan los desarrolladores (se actualizan desde él). Es la versión en desarrollo “en pruebas”.

En un momento dado se decide lanzar una nueva versión “estable”, se corrigen solamente fallos en la versión de pruebas(crew), y, finalmente, se actualiza con ella el repositorio “estable” (main).

Ejemplo de uso en el proyecto Pascaline

Se han organizado los repositorios publicados en el servidor así:

• un repositorio principal (main)
• un repositorio de integración de cambios (crew)
• tres repositorios personales (coya, ramon, pachi)

Cada uno trabaja sobre ramas locales que exporta a su repositorio personal y va integrando los cambios que se van generando en el repositorio de integración de cambios, para seguir el desarrollo que vayan haciendo los demás y poder integrar limpiamente los cambios propios en él sin generar nuevas ramas (cabezas) en dicho repositorio.

Se puede clonar el repositorio main así:

$ hg clone http://hg.rvburke.com/pascaline/main/ pascaline-main

el repositorio crew así:

$ hg clone http://hg.rvburke.com/pascaline/crew/ pascaline-crew

y el mío (pachi, o ramon, o coya):

$ hg clone http://hg.rvburke.com/pascaline/pachi/ pascaline-pachi

esto genera en nuestro sistema de archivos los directorios: pascaline-main, pascaline-crew y pascaline-pachi, que son tres repositorios de Mercurial.

para ir actualizándolo con los cambios que se vayan subiendo, simplemente se hace (dentro del directorio pascaline-main, pascaline-crew o pascaline-pachi):

$ hg pull
$ hg update

El primero trae los cambios remotos que no se encuentren ya en nuestra copia del repositorio y los guarda en el almacén de conjuntos de cambios, mientras que el segundo actualiza el estado del directorio al último cambio (‘tip’, por defecto).
hg pull no necesita aquí que se le indique el repositorio de origen porque, al clonarlo, almacena la referencia a la situación del repositorio de referencia (su dirección o su ruta en el sistema de archivos).

Uno puede trabajar en el proyecto de forma más segura haciendo otra copia local, y dejando esos repositorios como copias “limpias” del repositorio publicado en el servidor:

$ hg clone pascaline-pachi pascaline-pachi-para-trastear

Cambiamos algo y vamos guardando los pasos que queramos a medida que avanzamos en el desarrollo:

$ hg commit -m "He añadido una cosa a lo de pachi"

Esta orden (dentro de pascaline-pachi-para-trastear) guarda los cambios hechos como un nuevo changeset, por ejemplo, el 199.
(Podemos ver con hg log cuál es el último).

Para integrar los cambios en otras copias del proyecto podemos optar por hacer un parche de cada conjunto de cambios:

$ hg diff -r 199 > parche199.diff

o bien:

$ hg export 199 > parche199.mercurial

Esta última opción, export, genera más información útil para Mercurial que un simple parche con diff, y se puede integrar en otro repositorio con

$ hg import parche199.mercurial

O bien exportar a un archivo el lote cambios que no existe en el repositorio de destino. Las ordenes bundle y unbundle permiten generar e integrar esos archivos:

$ hg bundle cambios.bundle path/a/repo-destino

y (en el directorio del repositorio de destino):

$ hg unbundle cambios.bundle

Pero la forma más práctica y potente de trasladar los cambios es con push y pull.

Desde pascaline-pachi podemos traer los cambios desde pascaline-pachi-para-trastear así:

$ hg pull pascaline-pachi-para-trastear

o, desde pascaline-pachi-para-trastear, podemos llevar los cambios a pascaline-pachi:

$ hg push pascaline-pachi

en pascaline-pachi actualizamos a los últimos cambios:

$ hg update

y podemos subir los cambios al repositorio en el servidor de la misma manera, con push:

$ hg push http://hg.rvburke.com/pascaline/pachi/

ó, al usar la dirección por defecto (desde la que hemos clonado pascaline-pachi),

$ hg push

Los cambios que tenemos en el repositorio local deberían aparecer ahora en el repositorio publicado en el servidor.
El proceso es el mismo para trasladar cambios entre los directorios personales y crew, entre crew y main o entre cualesquiera otros repositorios.

…y en el próximo capítulo…

La próxima parte de esta serie de artículos tratará sobre la configuración del servidor para la publicación de repositorios, así como la configuración del acceso con ssh y claves públicas.

Introducción

En este artículo se hace una introducción a los conceptos necesarios para el trabajo con sistemas de control de versiones. En particular, se orienta al aprendizaje de Mercurial, un sistema de control de versiones de última generación y carácter distribuido escrito por Matt Mackall.
El artículo forma parte de una serie que se publicará en este blog, y que se estructura de la siguiente manera:

• I – Conceptos generales
• II – Uso de Mercurial
• III – Publicación de proyectos

Sistemas de control de versiones (VCS)

Mercurial es un programa que permite mantener un registro histórico de los cambios realizados en el contenido de un proyecto. Normalmente se utiliza en proyectos de software, pero se puede utilizar para otros propósitos (elaboración de documentos, archivo de la configuración de un sistema, etc).

Estos programas son conocidos como sistemas de control de versiones (VCS, por sus siglas en inglés), o sistemas de gestión de código (SCM).

La gran ventaja de tener un registro de cambios es la posibilidad de recuperar versiones antiguas, visualizar los cambios hechos entre dos versiones, la seguridad de poder hacer pruebas sabiendo que se pueden deshacer los cambios, la capacidad de reconciliar cambios entre distintas “ramas” de un mismo proyecto, etc…

Sistemas de control de versiones centralizados y distribuidos (DVCS)

Tradicionalmente, y en los sistemas centralizados, el registro de cambios de un proyecto se almacenaba en un único servidor, que contenía toda la información de su historia, y del que dependían los distintos clientes para realizar operaciones que implicasen modificar o consultar la historia del proyecto. El gran problema de estos sistemas es que deja sin todos los beneficios del uso de un sistema de control de versiones a las personas que no tienen permiso de acceso (fundamentalmente de escritura) al servidor.

Una nueva generación de sistemas de control de versiones, conocidos como sistemas de control de versiones distribuidos, permiten que toda la información acerca de la historia de un proyecto no haya de mantenerse en un único archivo central. En estos sistemas cada copia del proyecto contiene esa información, lo que permite que cada persona que trabaja con una copia disponga de todas las ventajas del control de versiones, y se facilita la colaboración, puesto que es posible relacionar los cambios realizados en diferentes copias, localizando su ancestro común a partir del cual se producen divergencias en el código común.

Este nuevo modelo favorece una participación más equitativa en equipos distribuidos y una organización menos jerarquizada, sin impedir por ello la posibilidad de un funcionamiento similar al que exigen los sistemas centralizados.

Si bien puede parecer que el coste de mantener información redundante en cada copia de un proyecto puede ser excesivo, en la práctica rara vez lo es, gracias al uso de técnicas de compresión y la similitud entre versiones sucesivas. Aún en proyectos muy grandes, con amplias historias de cambios, como el kernel Linux o FreeBSD, el espacio ocupado en disco para almacenar la historia de cambios no alcanza apenas al espacio ocupado por los archivos versionados.

Un poco de vocabulario: repositorios, conjuntos de cambios (Changeset) y estado del directorio (dirstate)

Mercurial registra la historia de un proyecto almacenando una especie de “instantáneas” del mismo en lo que se denomina “repositorio” (almacén, depósito).
Esas “instantáneas”, llamadas Changeset o conjuntos de cambios, contienen la versión en la que se encuentra cada uno de los archivos que se han “añadido” al repositorio, y son la pieza fundamental sobre la que se organiza Mercurial.

Así, el changeset 235 podría tener la versión 1 del archivo leeme.txt, la versión 5 del archivo COPYING, y no registra la existencia del archivo NEWS:

leeme.txt [versión 1]
COPYING [versión 5]

Por otra parte, el changeset 236 contiene el archivo leeme.txt en la misma versión (la 1), el archivo COPYING en la versión 6, y ya ha aparecido el archivo NEWS, en su versión 0:

leeme.txt [versión 1]
COPYING [versión 6]
NEWS [versión 0]

El conjunto de changesets de un proyecto podría ser algo así:

donde 0 es el changeset incial y (236) el último changeset registrado. Cada uno de esos estados del proyecto se registra indicando de forma explícita al sistema de control de versiones que se desean registrar los cambios. A esta operación se le conoce como hacer un envío de cambios o “commit“.

Algunos sistemas de control de versiones usan bases de datos para estructurar la información de los repositorios, pero, en Mercurial, un repositorio no es más que un directorio al que se añaden algunos metadatos. Estos metadatos los gestiona el sistema de forma transparente y automática, y están básicamente formados por los conjuntos de cambios del proyecto, además de por el estado actual del directorio de trabajo o “dirstate“.

El “dirstate” es el changeset padre, o el changeset del cual parte el contenido actual del directorio de trabajo. Este dato resulta necesario, puesto que el contenido del directorio de trabajo puede corresponder a cualquiera de las versiones registradas del proyecto o a una versión modificada de éstas… ya que el sistema permite navegar por la historia del proyecto.

En el esquema anterior, el dirstate sería el changeset 236, y contendría los siguientes archivos:

leeme.txt [versión 1]
COPYING [versión 6]
NEWS [versión 0]

Si modificamos esos contenidos, el changeset padre del directorio de trabajo seguiría siendo el 236, aunque los contenidos no serían iguales a dicha versión.

A la operación de recuperar en el directorio de trabajo una versión cualquiera de las registradas en el repositorio se le conoce como “actualizar” a una versión, y es una de las más útiles y habituales de las que permiten los sistemas de control de versiones.

En el ejemplo anterior, podríamos actualizar el directorio de trabajo a la versión 235:

de manera que el dirstate corresponde al changeset 235, y el contenido del directorio de trabajo sería:

leeme.txt [versión 1]
COPYING [versión 5]

Ramas, cabezas de desarrollo, reconciliación de cambios y tip

Hasta ahora hemos visto la historia de un proyecto como un registro lineal, pero lo más habitual es que se produzcan divergencias en la historia del mismo, dando lugar a lo que se conocen como “ramas” de desarrollo (“branches”).

Un ejemplo de aparición de divergencias es el siguiente:

• Se publica una nueva versión de un programa (v1.0 o changeset 212)
• Se siguen registrando nuevas funcionalidades en proceso de desarrollo (hasta el changeset 215)
• Surge un fallo inesperado en la versión publicada que exige la publicación de una nueva versión corregida
• Se actualiza el directorio de trabajo a la versión publicada (el dirstate cambia a 212)
• Se aplican las correcciones necesarias y se registra y publica la nueva versión (v1.1 o changeset 216)
• Se actualiza el directorio de trabajo para seguir trabajando en las nuevas funcionalidades (el dirstate cambia a 215)
• Se siguen añadiendo cambios (217)
• En este proceso acabamos con dos ramas: una versión incial más las nuevas funcionalidades (rama “en desarrollo“), una versión inicial con correcciones de fallos (rama “estable“).

Al changeset más reciente de cada rama se le conoce como cabeza (head) de la rama. En nuestro ejemplo serían los changeset 216 y el 217. Al changeset más reciente del repositorio se le conoce como tip, y al final del proceso de nuestro ejemplo, sería el changeset 217.

En el ejemplo anterior, es imaginable que se desee integrar los cambios de la rama “estable” en la rama en “desarrollo“.

A este proceso se le denomina reconciliación de cambios, mezcla de ramas, o “merging“, y Mercurial realiza esta operación añadiendo un nuevo changeset (218) que unifica dos changeset padre (normalmente las cabezas, en este caso 216 y 217), e incluye en él las modificaciones necesarias para reconciliar los cambios entre ellas.

Números de revisión, changeset ID y etiquetas

Hemos visto que la mayor parte de las operaciones, como la actualización a una versión determinada, o la mezcla de ramas, es necesario referirse a los changeset del repositorio. Para ello, Mercurial permite utilizar tres sistemas distintos: el número de revisión, el changeset ID, o un tag (etiqueta).

El número de revisión es simplemente un número natural que corresponde al orden en el que se registró del changeset en el repositorio. Es la forma que hemos usado hasta ahora en los ejemplos, pero presenta el problema de que no identifica de forma única a un determinado changeset, sino que puede cambiar de máquina a máquina, en función de las diferencias en la historia de cada copia de un repositorio. Por ello no es útil más que para referirse a una copia concreta de un repositorio.

El changeset ID es un identificador único para un changeset, que lo identifica en un punto concreto de la historia de un repositorio, y es indepediente de la máquina en la que se sitúe. Permite referirse al mismo changeset en distintas copias de un repositorio. En Mercurial es un dato de 160bits, normalmente representado como una secuencia de 20 caracteres.

Una etiqueta (tag) es simplemente una cadena de texto que se liga a un changeset ID, y permite identificarlo de forma más conveniente. En nuestro ejemplo la etiqueta “v1.0” puede estar ligado al changeset ID: 58deccf0bead81a34691095db485a19efa1be709, que correspondía al número de revisión 212, mientras que el número de revisión 216 está marcado con la etiqueta “v1.1“. En los esquemas se señalan las etiquetas en cajas amarillas.

…y en el próximo capítulo…

La próxima parte de esta serie de artículos tratará sobre la instalación y el uso práctico de Mercurial.

NOTA: El logo de Mercurial se distribuye bajo licencia GPL, según las condiciones establecidas en el sitio web de Mercurial