Hace ya algunos meses que hicimos la transición de subversion a  mercurial y creo que puede ser útil para otros el compartir los motivos que nos llevaron a decidir que era el momento de cambiar.

La situación de partida

En Agilogy siempre hemos trabajado con algún SCM. Al principio, durante unos meses, usamos CVS pero enseguida nos pasamos a subversion, que nos ha funcionado más o menos bien durante casi 7 años. Tenemos un servidor con subversion + apache + trac con algunos scripts de ruby para automatizar la creación de repositorios y el caso es que no hemos tocado mucho la configuración en todo este tiempo, lo cual dice mucho a favor de subversion (podríamos decir que el mantenimiento es casi nulo).

No obstante, en el último año habíamos tenido un par de sustos con subversion y las diferencias en la hora del servidor y los clientes (especialmente problemático cuando no todos los clientes están en la misma zona horaria). Nada grave (no llegamos a perder código) pero sí suficiente para erosionar un poco la confianza en subversion.

Otro problema que arrastrábamos de hacía tiempo eran los proyectos en los que se desarrollaba en varias ramas a la vez (en la línea del patrón ”feature branch”) ya los merge siempre eran complicados y, en la mayoría de casos, implicaban perder parte de la historia. De nuevo nada con lo que no pudiésemos convivir pero que no dejaba de ser molesto.

Finalmente, está el problema de la externalización. Dado que para trabajar con subversion es necesario tener conexión en todo momento al servidor (y esta debe ser rápida), subversion nos obliga a tener un servidor local que hay que administrar.

La decisión

A principios de 2011 volvimos a replantearnos todo el entorno de SCM y, a diferencia de otras ocasiones, nos planteamos utilizar un SCM distribuido de manera que podíamos romper la dependencia hacia el servidor físico de subversion y, por lo tanto, externalizar el servicio de SCM sin depender de la conexión a Internet. Además, el modelo distribuido se adapta mejor al desarrollo de varias ramas en paralelo (que son los proyectos en los que más necesitamos el SCM) y facilita enormemente la gestión de copias de seguridad (básicamente, cada desarrollador con una copia local es una copia de seguridad redundante del repositorio entero). Por todos estos motivos, decidimos darle una oportunidad al modelo distribuido.

Nuestra primera opción era github pero su modelo de licencia (por número de repositorios en lugar de por número de usuarios) no se adapta bien a nuestro contexto (en el momento de escribir este post tenemos unos 40 repositorios diferentes) por lo que buscamos alternativas, desde hospedar nuestra propia instalación de gitosis a otras alternativas como RepositoryHosting o XP-Dev. Finalmente, bitbucket nos convenció porque se trata de un producto bastante usable (no es github pero se le aproxima suficientemente), tiene un modelo de licencia que se adecúa a nuestra situación (por no decir que tiene una capa gratuita que permite tener repositorios privados :) ) y, además, tiene detrás a una compañía en cuyo criterio confiamos (Atlassian).

Sin embargo, bitbucket tenía un problema: Usaba mercurial en lugar de git. Probablemente, de no haber estado Atlassian detrás, habríamos ignorado esta opción pero, como acabo de decir, confiamos en el criterio de Atlassian, por lo que decidimos investigar un poco más y nos encontramos con que, no sólo podíamos hacer todo lo que nos interesaba de git sino que, además, la integración con windows era muy sencilla a través de TortoiseHg por lo que decidimos hacer una prueba piloto (al fin y al cabo, todas las herramientas que necesitábamos eran gratuitas).

Poco tiempo después, y satisfechos con el experimento, migramos todos los repositorios de subversion a mercurial y los publicamos en bitbucket (todo ello en menos de una mañana).

¿Volveríamos a migrar?

No hay nada de subversion que echemos de menos en mercurial y, a cambio, hemos ganado con unos merges más sencillos y podemos trabajar sin conexión al servidor. Es cierto que cuesta un poco adaptarse al nuevo sistema (sobre todo a que los commit no se publiquen de manera automática) pero gracias a tutoriales como éste el cambio ha sido muy fácil.

La migración de todos los repositorios fue muy sencilla (mercurial proporciona un script para migrar los repositorios que funciona bastante bien aunque algunos los tuvimos que migrar de manera “asistida”) y nos hemos quitado un peso de encima al no tener que administrar el servidor de subversion.

Por todo ello la respuesta es un sí rotundo.

¿Debería migrar todo el mundo?

Dado que conozco a poca gente que use mercurial (y, en general, a pocas empresas que usen un SCM distribuído “en producción”) creo que nuestra experiencia puede ser interesante para otros que se estén planteando esta misma decisión.

Lo primero que hay que tener en cuenta es que no “hace falta” migrar. Nosotros hemos estado, como he dicho, 7 años con subversion y, probablemente, podríamos haber estado 7 más. Mercurial no hace que escribamos el código más rápido ni mejor. Eso sí, la combinación mercurial + bitbucket nos ha liberado algo de tiempo (el que dedicábamos a administrar el servidor de subversion) y nos ha permitido organizarnos en algunos proyectos de maneras que con subversion no podíamos, mientras que para otros hemos podido mantener exactamente la misma organización que teníamos.

Respecto a mercurial vs git, en nuestro caso la presencia de TortoiseHg para los clientes windows (en MacOS ya es otra historia) y el modelo de licencia de bitbucket fueron decisivos. Es posible que, si tuviésemos que tomar la decisión hoy, ésta fuese diferente; no lo sé y no me preocupa: lo que me interesaba era la combinación de SCM distribuido + hosting en la nube y eso ya lo tenemos; además, la migración de mercurial a git es muy sencilla por lo que, cuando dentro de un tiempo nos volvamos a plantear si las herramientas que usamos son las que queremos usar, la migración de los repositorios será un factor más a tener en cuenta junto a los clientes para windows, el soporte de eclipse, etc.

Por último, hay que tener en cuenta que en Agilogy somos un equipo pequeño y con una resistencia al cambio muy baja (no nos importa probar cosas nuevas si creemos que vamos a ganar con el cambio) pero esto no tiene por qué ser aplicable a otros entornos.