sábado, 17 de mayo de 2008

Sistemas de Control de Versiones Distribuidos

Un sistema de control de versiones (SCM) es el responsable de mantener las trazas de varias revisiones de la misma unidad de información. Se utiliza normalmente en proyectos de desarrollo de software para gestionar el código del proyecto, pero también puede usarse para gestionar versiones de documentación de cualquier tipo de proyecto de la empresa.

El primer proyecto SCM fue CVS y consta de 1986, desde entonces muchos otros proyectos han florecido: Perforce(1995), CVSNT(1998), Subversion (2000) cada uno con sus peculiaridades y ventajas.

En Mayo de 2007 Linus Torvalds realizó una presentación sobre git y desde entonces el interés por los sistemas de control de versiones distribuidos (DVCS) ha ido aumentando considerablemente. Sebastian Auvrey editor de InfoQ muestra en un excelente artículo las ventajas de este tipo de sistemas que resumimos a continuación.

Un sistema DVCS moderno resuelve asuntos que no resuelven los sistemas VCS centralizados tales como:


  • Realizar distintas ramas es fácil pero fusionarlas no lo es. Subversion por ejemplo no dispone de fusión de históricos, lo que fuerza a los usuarios a realizar estas tareas a mano.
  • No hay manera de enviar los cambios a otro usuario si no es pasando por el servidor central.
  • Subversion falla al fusionar cambios cuando los nombres de los ficheros o directorios han sido renombrados.
  • La convención de nombres de subversion de las distintas Ramas/etiquetas/Trunks puede ser engañosa.
  • No es posible realizar commits offline.
  • Los archivos .svn contaminan los directorios locales.

Descentralización

DVCS tienen la ventaja de los sistemas peer-to-peer. Los clientes pueden comunicarse con otros y mantener sus propias ramas locales sin la necesidad de acceder a un repositorio central, La sincronización tiene lugar entre los peers que deciden que partes intercambiar.





CVCSvsDVCS
CVCSvsDVCS[1]


Esto da como resultado unas diferencias con respecto a los sistemas centralizados:

  • Sólo se trabaja con copias.
  • Operaciones normales como commits, vista de históricos, diferencias, y rollbacks son más rápidas porque no hay necesidad de comunicar con un sistema central.
  • Cada copia de trabajo es vista como un backup remoto proporcionando así un sistema natural de seguridad contra pérdida de datos.
  • Crear y borrar nuevas ramas son operaciones simples y rápidas.
  • La colaboración entre los distintos peers se hace fácil.






Esquema de VCS Centralizado
VCS Centrallizado







Esquema de VCS Distribuido
VCS Distribuido


La diferencia está en que en un repositorio centralizado, todo el mundo realiza las operaciones de commit, backup, tracing y sincronización sobre el mismo tronco y en uno distribuido cada usuario tiene su propio repositorio que comparte completo o sólo la rama necesaria con otros desarrolladores. Sin embargo, no hay que pensar que esto pueda dar con un caos sin regulación ya que si es necesario todos pueden notificar los cambios a un repositorio común, algo similar al centralizado que recogerá los últimos cambios de cada usuario.

La versión distribuida se centra en compartir los cambios mediante la asignación de un id único. Asimismo, las operaciones de Descarga/Grabación o aplicar son operaciones separadas mientras que en un sistema centralizado operan de manera conjunta. Además, el sistema distribuido no fuerza la estructura permitiendo crear sitios administrados "centralmente" o bien mantener a todos como peers.

Workflows

Sobre las distintas estrategias a utilizar a la hora de diseñar un workflow puede echarse un vistazo al artículo de bazaar el cuál se resume a continuación:


Estrategia Solo:


Workflows[1]


Estrategia Partner


Workflows[1]


Estrategia centralizada


Workflows[1]


Estrategia centralizada con commits locales


Workflows[1]


Estrategia descentralizada con parte principal compartida


Workflows[1]


Estrategia descentralizada con puerta de enlace humana


Workflows[2]


Estrategia descentralizada con puerta de enlace automática


Workflows[1]


Software

Los principales desarrollos de este tipo de sistemas son Mercurial (Apr, 2005), Bazaar (Mar, 2005), darcs (Nov, 2004), Monotone (Apr, 2003) y el propio git ya mencionado anteriormente.


Una tabla comparativa con las características principales de cada herramienta puede encontrarse en el artículo de Sebastian Auvrey. Parece que git se lleva la palma en cuanto a rapidez pero como bien se recoge en algunos debates es debido a su buena integración con Linux ya que hace uso de características nativas de este sistema operativo.


Ventajas y desventajas


Ventajas


  • Todos los participantes tienen su propia caja de arena. Es decir puedes hacer cambios, roll backs y tus históricos permanecerán en tu repositorio local sin necesidad de hacer checkins gigantes.
  • Trabaja offline. Sólo necesitas estar online para compartir cambios. No pasa nada si el servidor está caído.
  • Es más rápido. Los Diffs, commits y reverts son hechos en local.
  • Maneja los cambios mejor. Los sistemas distribuidos se han creado bajo la premisa de compartir los cambios. Cada cambio tiene un guid que hace fácil su traza.
  • La creación y fusión de ramas es más fácil. Porque cada desarrollador tiene su propia rama y cuando se comparte es como realizar una integración inversa. El guid hace eso automáticamente combinando los cambios y evitando duplicados.
  • Menos gestión. No es necesario un servidor siempre activo, ni la necesidad de añadir nuevos usuarios, lo que evita los quebraderos de cabeza en proyectos grandes.

Desventajas


  • Todavía necesitas un sistema de backup. No hay que fiarse de que el backup reside en el otro(s) usuario(s), ya que este puede no admitirte más, o estar inactivo mientras que yo tengo cambios hechos, por lo que todavía será necesario un servidor central donde realizar los backups "para esos casos".
  • Realmente no hay una "última versión". Si no hay un repositorio central no hay manera de saber cuál es la última versión estable del producto.
  • Realmente no hay números de versión. Cada repositorio tiene sus propios números de revisión dependiendo de los cambios. En lugar de eso, la gente pide la última versión del guid concreto (un número verdaderamente feo). Afortunadamente cabe la posibilidad de etiquetar cada versión con un nombre más amigable.

Fuentes:


InfoQ
Intro to Distributed Version Control
Workflows
Patch Theory

No hay comentarios:

Articulos relacionados