Debido a que los repositorios de Openbravo son de Mercurial, en los últimos meses me he tenido que acostumbrar con ese sistema de control de versiones (SCV).

Para alguien que sólo ha trabajado con Subversion (o anteriores), esto significa un importante cambio de filosofía, puesto que Mercurial se engloba dentro de los más modernos sistemas de control de versiones distribuidos (como Git, Bazaar y otros). Lo que voy a contar es específico de Mercurial, pero estos cambios vienen motivados por su característica de distribuido.

El principal cambio es respecto a la redifinición de los conceptos de cliente y servidor. En SVN, la separación está muy clara: el servidor aloja las versiones y se encarga de su gestión. Por otro lado, los distintos clientes se bajan copias del servidor, realizan cambios, y envían esos cambios al servidor.

En toda esta relación está claro quién es quién. En nuestra máquina local tenemos el cliente, y en el servidor el repositorio. Con Mercurial la cosa cambia mucho, porque cada copia del repositorios es a la vez cliente y servidor. En lugar de hacer checkout, para hacerte con un repositorio cliente del servidor, haces clone, con lo que creas un nuevo repositorio cliente-servidor copia del anterior. Las operaciones de commit y update funcionan en local, mientras que se introducen nuevas operaciones (pull y push) para intercambiar cambios entre repositorios. Todo junto quedaría en el siguiente esquema:

Esta estructura es bastante más compleja que un SCV tradicional, pero ofrece una serie de ventajas que compensan el aprendizaje inicial. Se suele decir que las principales ventajas son relativas a proyectos grandes, con un montón de colaboradores y varias personas validando grupos de estos colaboradores. Sin embargo, mi experiencia es que incluso cuando hay un único desarrollador, hay beneficios importantes.

Una ventaja que puede parecer secundaria, pero que a mí me encanta, es la capacidad de realizar commits locales. Esto permite trabajar con el control de versiones aún cuando no tienes acceso al servidor princiapl (circunstancia muy frecuente). Esto permite que los desarrolladores incomunicados puedan hacer commits con cambios pequeños y atómicos, en lugar de realizar un envío masivo donde todos los cambios van a tropel y hacen inmanejables logs, control de cambios y vueltas atrás.

Hablando de vueltas atrás, con Mercurial también es posible revertir cualquier fichero a cualquier revisión sin necesidad de conexión con el servidor. Los programadores que se han visto en estas situaciones adversas (como proxies) durante largos periodos pueden valorar estas ventas.

Pero quizá la ventaja más importante está en el prácticamente nulo esfuerzo requerido para clonar repositorios. Por ejemplo, cada vez que un cliente nuevo requiere una personalización de Openbravo POS, se le puede crear un nuevo repositorio simplemente clonándolo. Luego cada desarrollador clonaría de este nuevo repositorio y compartirían los cambios a partir de él.

Si es el caso de OpenTPV, la versión de Opensistemas de Openbravo POS para negocios de restauración, la estructura sería Openbravo POS -> OpenTPV -> versión del cliente . Si hay cambios en el repositorio principal de Openbravo POS, es trivial irla bajando a OpenTPV y a sus modificaciones. Si arreglamos un bug, dependiendo de la raíz del problema, podemos corregir Openbravo POS, OpenTPV o la versión del cliente, y luego difundir esos cambios a los que corresponda.

La única desventaja que le encuentro a Mercurial es que requiere algo más de control y pensar bien cómo organizar estos repositorios. En otras entradas planeo contar un poco más de esto ya que, por si no se ha notado, Mercurial me ha encantado.

Por todo esto, yo recomendaría su uso, o al menos probarlo. Quizá algún día merezca implantarlo a nivel oficial en la empresa, como alternativa al madurito Subversion.