2

Sistemas de control de versiones

Sistemas de control de versiones locales

El método de elección de control de versión de muchas personas es copiar archivos en otro directorio (quizás un directorio con marca de tiempo, si son inteligentes). Este enfoque es muy común porque es muy simple, pero también es increíblemente propenso a errores. Es fácil olvidar en qué directorio se encuentra y escribir accidentalmente en el archivo incorrecto o copiar sobre archivos que no quiere.

Para lidiar con este problema, los programadores desde hace mucho tiempo desarrollaron VCS locales que tenían una base de datos simple que mantenía todos los cambios a los archivos bajo el control de revisión.

Una de las herramientas VCS más populares fue un sistema llamado RCS, que todavía se distribuye con muchas computadoras en la actualidad. RCS funciona manteniendo los conjuntos de parches (es decir, las diferencias entre archivos) en un formato especial en el disco; luego puede volver a crear el aspecto de cualquier archivo en cualquier momento sumando todos los parches.

Sistemas de control de versiones centralizados

El siguiente problema importante que las personas encuentran es que necesitan colaborar con los desarrolladores en otros sistemas. Para resolver este problema, se desarrollaron los Sistemas de Control de Versiones Centralizados (CVCS). Estos sistemas (como CVS, Subversion y Perforce) tienen un único servidor que contiene todos los archivos versionados y una cantidad de clientes que revisan archivos desde ese lugar central. Durante muchos años, este ha sido el estándar para el control de versiones.

Esta configuración ofrece muchas ventajas, especialmente sobre los VCS locales. Por ejemplo, todos saben hasta cierto punto lo que hacen los demás en el proyecto. Los administradores tienen un control detallado sobre quién puede hacer qué, y es mucho más fácil administrar un CVCS que tratar con bases de datos locales en cada cliente.

Sin embargo, esta configuración también tiene algunas desventajas serias. El más obvio es el único punto de falla que representa el servidor centralizado. Si ese servidor deja de funcionar durante una hora, durante esa hora nadie podrá colaborar o guardar cambios versionados en cualquier cosa en la que estén trabajando. Si el disco duro en el que se encuentra la base de datos central se corrompe y no se han guardado las copias de seguridad adecuadas, perderá absolutamente todo: todo el historial del proyecto, excepto las instantáneas que la gente tenga en sus máquinas locales. Los sistemas VCS locales sufren este mismo problema: siempre que tenga el historial completo del proyecto en un solo lugar, corre el riesgo de perderlo todo.

Sistemas distribuidos de control de versiones

Aquí es donde intervienen los Sistemas de control de versiones distribuidas (DVCS). En un DVCS (como Git, Mercurial, Bazaar o Darcs), los clientes no solo revisan la última instantánea de los archivos; más bien, reflejan completamente el repositorio, incluida su historia completa. Por lo tanto, si algún servidor muere y estos sistemas colaboran a través de ese servidor, cualquiera de los repositorios de clientes se puede copiar de nuevo en el servidor para restaurarlo. Cada clon es realmente una copia de seguridad completa de todos los datos.

Además, muchos de estos sistemas se ocupan bastante bien de tener varios repositorios remotos con los que pueden trabajar, por lo que puede colaborar con diferentes grupos de personas de diferentes maneras simultáneamente dentro del mismo proyecto. Esto le permite configurar varios tipos de flujos de trabajo que no son posibles en los sistemas centralizados, como los modelos jerárquicos.

Derechos de autor: GIT

Escribe tu comentario
+ 2
1

Thank you for sharing this great data for us. Very valuable article. Really increase the value in the way you described everything in this article. Keep up the good work
fnaf