Comparación de servidores de desarrollo: Mercurial vs SVN

Subversion:

Subversion es un servidor de control de versiones centralizado. Está pensado para que varias personas puedan trabajar bajo el mismo proyecto sin interferirse mutuamente. Contiene un histórico de versiones que facilita la recuperación de codificaciones antiguas en el caso de que fuera necesario hacer uso de código ya modificado. También permite gestionar distintas versiones de la misma aplicación o proyecto, “trunks”, “branches”.
Para trabajar con Subversion, se suelen realizar las implementaciones sobre el equipo local, no sobre el servidor.

El costo de complejidad de la creación de estas ramas o etiquetas es constante, no lineal. Las modificaciones se realizan de forma atómica (o se actualiza el fichero entero o no se actualiza nada). Permite bloquear los ficheros que se quieren modificar, de esta manera sólo una persona al mismo tiempo estará modificando la misma clase y así se evitan problemas de incoherencias. En el caso de que exista algún tipo de incoherencia, permite descargar las modificaciones que hay en el servidor pero mantiene en el directorio local un versionado con las últimas revisiones. De esta forma se puede valorar qué es el código relevante antes de actualizar el servidor. Las revisiones sólo se realizan sobre los cambios o modificaciones, no sobre la totalidad del fichero.

En Subversión, las ramas se crean a partir de un enlace a un número de revisión del código y las tags o etiquetas no son más que ramas a las que no se le añaden cambios.

Los cambios se realizan sobre el servidor, dejando constancia de todos ellos sobre un histórico y son identificados de 3 maneras:

– Usuario.

– Número de revision.

– Comentarios en “commit”.

Mercurial

Por su parte, Mercurial es un servidor de control de versiones distribuido, esto significa que cada desarrollador dispone de una copia completa del repositorio, permitiéndole el manejo de las distintas versiones sin conexión. Está orientado a grandes proyectos por su velocidad de operacional y es independiente (hasta cierto punto) de la plataforma ya que, está hecho en Python en su mayor parte.

Es un servidor de código abierto que permite, de forma sencilla, modificaciones y la adición de plugins. La curva de aprendizaje es poco pronunciada ya que inicialmente la cantidad de comandos es baja y son parecidos a los de SVN.

Su rendimiento es alto en cuanto a la velocidad de ejecución de comandos y operaciones y bajo en la gestión de espacio en disco ya que siempre Mercurial está estructurado de tal forma que siempre se añaden objetos al repositorio.

El acceso al repositorio se puede controlar de tres maneras: Mediante una cuenta SSH compartida, mediante un servidor apache con soporte para el protocolo HTTPS y scripts .cgi y mediante un grupo de usuarios del sistema de archivos.

A efectos operacionales Mercurial trata todos los cambios en el código como una serie de branches y merges.

Existen 4 maneras de trabajar con branches en mercurial:

• La manera más sencilla pero más lenta de realizar branches es creando nuevos clones del repositorio.
• Otra forma es utilizar tags o bookmarks. Esta estrategia permite realizar un seguimiento del desarrollo de manera ligera y rápida.
• La tercera posibilidad es mediante named branches. En este caso creamos ramas de desarrollo independientes. Considero que para cambios importantes es uno de los métodos más recomendables pero para pequeños cambios supone demasiado gasto de recursos.
• La última manera de crear branches es la más sencilla y rápida. Simplemente consiste en hacer updates y commits. Con esta estrategia simplemente establecemos una rama sin especificar ningún nombre.

Recordaremos que los “merges” en este caso no son simétricos por lo que establecerá la rama más antigua como la principal y a esta unirá la más actual. Para hacer un merge, utilizaremos el commando hg merge. En ese momento Mercurial recuperará los contenidos de cada versión HEAD y los une en el directorio de trabajo, dejando constancia de cada uno de ellos hasta que se realice un commit. En caso de encontrar conflictos, Mercurial buscará algún software para hacer merge automáticamente instalado en el sistema ya que no cuenta con ningún módulo para la gestión de estos conflictos. Si no lo encuentra o se requiere la interacción del usuario, intentará lo mismo con programas con entorno visual.

En Mercurial el seguimiento de los cambios se realiza en el repositorio y en un solo archivo, minimizando los costos de acceso a disco ya que no necesita buscar el archivo en cada directorio.

Para identificar revisiones existen 3 criterios que se pueden seguir:

• Según el número (decimal) de revisión que se corresponde con el orden de los commits en el repositorio local.
• Mediante el changeset ID que identifica la posición de la revisión en cualquier con respecto a la historia total del proyecto y que consta de 160 bits (40 dígitos hexadecimales).
• Según tags que añaden contenido semántico al changeset ID.

Como hemos dicho, Mercurial es multiplataforma (existen versiones tanto de cliente como de servidor para Linux, Mac, Windows y Solaris). Esto debe a que está escrito en Phyton en su mayoría y sólo una parte del código está programado en C. Además, aunque no he revisado el código fuente, en la página principal de este servidor de control de versiones indican que esta parte es fácilmente portable.

Como vemos, estos servidores son diametralmente opuestos. Ya que están orientados a dos tipos de proyectos distintos. Para proyectos más pequeños y centralizados en cuanto a localización de los desarrolladores, consideramos más oportuno el uso de SVN. Para proyectos más grandes y con un mayor grado de distribución en cuanto a localización de los desarrolladores es más recomendable el uso de Mercurial. Por lo tanto, a la hora de elegir entre un sistema u otro deberemos tener bien definido nuestro proyecto.

Post publicado por:   Juan José Hernandez