Sistema de versiones concurrentes

El Sistema de Versiones Concurrentes ( CVS , o Sistema de Versionado Concurrente ) es un sistema de control de versiones desarrollado originalmente por Dick Grune en julio de 1986. ^{[ 4 ]} Se basa en un sistema de control de versiones anterior llamado Sistema de Control de Revisiones (RCS), al que añade soporte para el seguimiento de cambios a nivel de repositorio y un modelo cliente-servidor. Los servidores CVS normalmente se ejecutan en sistemas Unix , mientras que los clientes pueden estar en cualquier sistema operativo .

CVS funciona como una interfaz para el Sistema de Control de Revisiones (RCS), un sistema de control de versiones anterior que gestiona archivos individuales pero no proyectos completos. Amplía las funcionalidades de RCS añadiendo soporte para el seguimiento de cambios a nivel de repositorio y un modelo cliente-servidor. ^{[ 5 ]} Los archivos se rastrean utilizando el mismo formato de historial que en RCS, con un directorio oculto que contiene un archivo de historial correspondiente para cada archivo en el repositorio.

CVS utiliza compresión delta para almacenar de forma eficiente diferentes versiones de un mismo archivo. Esto funciona bien con archivos de texto grandes con pocos cambios entre versiones, como suele ser el caso de los archivos de código fuente. Por otro lado, cuando se le indica a CVS que almacene un archivo como binario, conservará cada versión individual en el servidor. Esto se suele utilizar para archivos que no son de texto, como imágenes ejecutables, donde resulta difícil crear deltas compactos entre versiones.

CVS excluye los enlaces simbólicos porque, al almacenarse en un sistema de control de versiones, pueden suponer un riesgo de seguridad. Por ejemplo, un enlace simbólico a un archivo confidencial puede almacenarse en el repositorio, lo que permite acceder a dicho archivo incluso cuando no está registrado. En lugar de enlaces simbólicos, se pueden registrar en CVS scripts que requieren ciertos privilegios e intervención explícita para su ejecución.

CVS etiqueta un proyecto individual (conjunto de archivos relacionados) que gestiona como un módulo . Un servidor CVS almacena los módulos que gestiona en su repositorio . Los programadores obtienen copias de los módulos extrayéndolas . Los archivos extraídos sirven como copia de trabajo , entorno aislado o espacio de trabajo . Los cambios en la copia de trabajo se reflejan en el repositorio al confirmarlos . Actualizar consiste en adquirir o fusionar los cambios del repositorio con la copia de trabajo.

CVS utiliza una arquitectura cliente-servidor : un servidor almacena la(s) versión(es) actual(es) de un proyecto y su historial, y los clientes se conectan al servidor para "extraer" una copia completa del proyecto, trabajar en ella y, posteriormente, "confirmar" sus cambios. Los servidores CVS permiten el "acceso de lectura anónimo" ^{[ 6 ]} , en el que los clientes pueden extraer y comparar versiones con una contraseña en blanco o una contraseña publicada sencilla (por ejemplo, "anoncvs"); solo la confirmación de cambios requiere una cuenta y contraseña personales en estos casos. Varios desarrolladores pueden trabajar en el mismo proyecto simultáneamente, cada uno editando archivos en su propia "copia de trabajo" del proyecto y enviando (o confirmando ) sus modificaciones al servidor. Para evitar conflictos, el servidor solo acepta los cambios realizados en la versión más reciente de un archivo. Por lo tanto, se espera que los desarrolladores mantengan su copia de trabajo actualizada incorporando los cambios de otros usuarios de forma regular. Esta tarea la realiza automáticamente el cliente CVS, requiriendo intervención manual únicamente cuando surge un conflicto de edición entre una modificación confirmada y la versión local aún no confirmada de un archivo. Los clientes también pueden usar el comando "update" para actualizar sus copias locales con la versión más reciente del servidor. Asimismo, pueden comparar versiones, solicitar un historial completo de cambios o consultar una instantánea histórica del proyecto (por ejemplo, basada en una fecha determinada). Si la operación de confirmación se realiza correctamente, los números de versión de todos los archivos involucrados se incrementan automáticamente y el servidor escribe una línea de descripción proporcionada por el usuario, la fecha y el nombre del autor en sus archivos de registro . CVS también puede ejecutar scripts externos de procesamiento de registros, especificados por el usuario, después de cada confirmación. Estos scripts se instalan mediante una entrada en loginfoel archivo de configuración de CVS, que puede activar notificaciones por correo electrónico o convertir los datos de registro a un formato web.

CVS también puede mantener diferentes "ramas" de un proyecto. Por ejemplo, una versión publicada del proyecto de software puede formar una rama, utilizada para la corrección de errores, mientras que una versión en desarrollo, con cambios importantes y nuevas funcionalidades, puede formar una rama separada. CVS asume que la mayor parte del trabajo se realiza en la rama principal y que las ramas generalmente deben ser efímeras o históricas. Cuando se utiliza según lo previsto, las ramas se gestionan fácilmente y las operaciones con ellas son eficientes y rápidas. ^{[ 7 ] [ 8 ]}

Los desarrolladores del software del servidor lo escriben para Unix , aunque el servidor CVSNT también es compatible con varias versiones de Microsoft Windows , mientras que los clientes CVS pueden ejecutarse en cualquier plataforma de sistema operativo importante .

Grune recordó: ^{[ 9 ]}

Creé CVS para poder colaborar con mis estudiantes, Erik Baalbergen y Maarten Waage, en el compilador C ACK ( Amsterdam Compiler Kit ). Los tres teníamos horarios muy diferentes (uno trabajaba de 9 a 5, el otro tenía horarios irregulares y yo solo podía trabajar en el proyecto por las noches). Su proyecto se desarrolló desde julio de 1984 hasta agosto de 1985. Inicialmente, CVS se llamaba cmt, por la obvia razón de que nos permitía confirmar versiones de forma independiente.

Grune publicó el código públicamente el 23 de junio de 1986. ^{[ 10 ]}

El código que finalmente evolucionó hasta convertirse en la versión actual de CVS comenzó con Brian Berliner en abril de 1989, con aportaciones posteriores de Jeff Polk y muchos otros colaboradores. Brian Berliner escribió un documento que presentaba sus mejoras al programa CVS, el cual describe cómo la herramienta fue extendida y utilizada internamente por Prisma, un desarrollador externo que trabajaba en el núcleo de SunOS, y fue publicada para beneficio de la comunidad bajo la GPL. ^{[ 11 ]} El 19 de noviembre de 1990, la versión 1.0 de CVS fue presentada a la Free Software Foundation para su desarrollo y distribución. ^{[ 12 ]}

La última versión se publicó el 8 de mayo de 2008. ^{[ 13 ]}

En el mundo del software de código abierto, el Sistema de Versiones Concurrentes (CVS) ha sido durante mucho tiempo la herramienta preferida para el control de versiones. Y con razón. CVS es software libre, y su modo de operación no restrictivo y su compatibilidad con el funcionamiento en red —que permite que decenas de programadores geográficamente dispersos compartan su trabajo— se adaptan perfectamente a la naturaleza colaborativa del mundo del código abierto. CVS y su modelo de desarrollo semi-caótico se han convertido en pilares fundamentales del código abierto. ^{[ 14 ]}

Con el tiempo, los desarrolladores han creado nuevos sistemas de control de versiones basados ​​en CVS para añadir funcionalidades, modificar el modelo operativo y mejorar la productividad de los desarrolladores. Entre los proyectos que sustituyen a CVS se encuentran CVSNT y Subversion . ^{[ 15 ] [ 16 ]}

• Comparación de software de control de versiones
• Cervisia
• OpenGrok
• TortugaCVS
• ViewVC

• Sitio web oficial