Control de versiones distribuido
En programación informática, el control de versiones distribuido permite a muchos desarrolladores de software trabajar en un proyecto común sin necesidad de compartir una misma red. Las revisiones son almacenadas en un sistema de control de versiones distribuido (DVCS, por sus siglas en inglés).
Distribuido vs. Centralizado
El control de versiones distribuido toma un enfoque entre iguales (peer-to-peer), opuesto al enfoque de cliente-servidor de los sistemas centralizados. En lugar de un único repositorio central en el cual los clientes se sincronizan, la copia local del código base de cada peer es un repositorio completo.
El control de versiones distribuido sincroniza los repositorios intercambiando ajustes (conjuntos de cambios) entre iguales. Esto establece algunas diferencias importantes en comparación a un sistema centralizado:
- No existe una copia de referencia del código base por defecto; solo copias de trabajo.
- Operaciones comunes (como commits, visualización del historial, y revertir cambios) son rápidas, porque no existe necesidad de comunicación con un servidor central.
- La comunicación con el servidor sólo es necesaria cuando se comparten cambios entre iguales (peers).
- Cada copia de trabajo funciona efectivamente como una copia de seguridad remota del codebase y de su historial de cambios, protegiéndolo de la pérdida de datos.
Otras diferencias incluyen:
- Múltiples repositorios “centrales”.
- El código discrepante de los repositorios es fusionado sobre la base de una red de confianza. Por ejemplo, el histórico de méritos o calidad de cambios.
- Numerosos modelos de desarrollo diferentes son posibles, como el desarrollo/lanzamiento de ramas de un modelo Comandante/Teniente, permitiendo la delegación eficiente del desarrollo de tópicos in proyectos de gran tamaño. Los tenientes son proyectos miembro que tienen la capacidad de decidir de forma dinámica qué ramas unificar (fusionar).
- La red no está involucrada en operaciones comunes.
- Un conjunto separado de operaciones de sincronización están disponibles para confirmar o recibir cambios con repositorios remotos.
Los propulsores del control de versiones distribuido señalan numerosas ventajas de los sistemas de control de versiones distribuido sobre el modelo centralizado tradicional:
- Permite a los usuarios trabajar de forma productiva cuando no están conectados a la red.
- Realiza las operaciones más rápido.
- Permite la participación en proyectos sin requerir permiso de las autoridades, y por lo tanto fomenta la cultura de la meritocracia.
- Permite el trabajo en forma privada, de modo que los usuarios pueden utilizar sus cambios incluso en iteraciones intermedias que no quieren publicar.
- Evita confiar en una única máquina física como único punto de fallas.
- Permite el control centralizado de las versiones de lanzamiento del proyecto.
- En proyectos de software FLOSS es mucho más fácil crear una bifurcación del proyecto desde un proyecto que está detenido por los conflictos de liderazgo o desacuerdos en el diseño.
Joel Spolsky, autor dedicado al Desarrollo de Software y dueño de un sistema de control de versiones distribuido, describe el control de versiones distribuido como “posiblemente el más grande avance en tecnologías de desarrollo de software en (los últimos) diez años”.[1]
Una desventaja es que la clonación inicial de un repositorio es más lenta comparada a la centralizada, porque todas las ramas y el historial de revisiones son copiados. Esto puede ser significativo si la velocidad de acceso es lenta y el tamaño del repositorio es lo suficientemente grande. Por ejemplo, el tamaño del repositorio git clonado (todo el historial, ramas, etiquetas, etc.) del núcleo Linux es aproximadamente el tamaño del HEAD comprobado descomprimido, mientras la comprobación (checkout) equivalente de una única rama en una comprobación centralizada sería del tamaño comprimido del HEAD (exceptuando todo el historial, ramas, etiquetas, etc.). Otro problema del control de versiones distribuido es la cantidad de mecanismos de bloqueo que son parte de DVCS más centralizados y ocupan aun un rol importante cuando se trata de archivos binarios no fusionables como activos gráficos (graphic assets).
Referencias
- Spolsky, Joel (17 de marzo de 2010). «Distributed Version Control is here to stay, baby». Joel on Software. Consultado el 18 de junio de 2010.