Saltar la navegación

2.2.- Estructura de herramientas de control de versiones.

Caso práctico

Hombre de pie mirando de frente.

Para Ana el concepto de control de versiones le resulta muy abstracto. Juan va a intentar explicarle como funciona el mecanismo de control de versiones, tomando como ejemplo una herramienta que él conoce: CVS.

Imagen que muestra dos rectángulos, uno azul y otro verde. En el rectángulo azul se muestra un grafo con la estructura de archivos y directorios de una aplicación, Para gestionar las diferentes versiones, se aplican las operaciones add, edit, borrar, y abort, que están representadas mediante fechas. Si se ejecuta un commit, todos los elementos de la aplicación se almacen en el repositorio (cuadrado verde donde está el CVSROOT y todas las versiones almacenadas de la aplicación). Si queremos obtener una versión almacenada en el repositorio, se realiza la operación Checkout, y recuperariamos los almacenado en el repositorio.

Las herramientas de control de versiones, suelen estar formadas por un conjunto de elementos, sobre los cuales, se pueden ejecutar órdenes e intercambiar datos entre ellos. Como ejemplo, vamos a analizar ha herramienta CVS.

Una herramienta de control de versiones, como CVS, es un sistema de mantenimiento de código fuente (grupos de archivos en general) extraordinariamente útil para grupos de desarrolladores que trabajan cooperativamente usando alguna clase de red. CVS permite a un grupo de desarrolladores trabajar y modificar concurrentemente ficheros organizados en proyectos. Esto significa que dos o más personas pueden modificar un mismo fichero sin que se pierdan los trabajos de ninguna. Además, las operaciones más habituales son muy sencillas de usar.

CVS utiliza una arquitectura cliente-servidor: un servidor guarda la versión actual del proyecto y su historia, y los clientes conectan al servidor para sacar una copia completa del proyecto, trabajar en esa copia y entonces ingresar sus cambios. Típicamente, cliente y servidor conectan utilizando Internet, pero cliente y servidor pueden estar en la misma máquina. El servidor normalmente utiliza un sistema operativo similar a Unix, mientras que los clientes CVS pueden funcionar en cualquier de los sistemas operativos más difundidos.

Los clientes pueden también comparar diferentes versiones de ficheros, solicitar una historia completa de los cambios, o sacar una "foto" histórica del proyecto tal como se encontraba en una fecha determinada o en un número de revisión determinado. Muchos proyectos de código abierto permiten el "acceso de lectura anónimo", significando que los clientes pueden sacar y comparar versiones sin necesidad de teclear una contraseña; solamente el ingreso de cambios requiere una contraseña en estos escenarios. Los clientes también pueden utilizar el comando de actualización con el fin de tener sus copias al día con la última versión que se encuentra en el servidor. Esto elimina la necesidad de repetir las descargas del proyecto completo.

El sistema de control de versiones está formado por un conjunto de componentes:

  • Repositorio: es el lugar de almacenamiento de los datos de los proyectos. Suele ser un directorio en algún ordenador.
  • Módulo: en un directorio especifico del repositorio. Puede identificar una parte del proyecto o ser el proyecto por completo.
  • Revisión: es cada una de las versiones parciales o cambios en los archivos o repositorio completo. La evolución del sistema se mide en revisiones. Cada cambio se considera incremental.
  • Etiqueta: información textual que se añada a un conjunto de archivos o a un módulo completo para indicar alguna información importante.
  • Rama: revisiones paralelas de un módulo para efectuar cambios sin tocar la evolución principal. Se suele emplear para pruebas o para mantener los cambios en versiones antiguas.

Algunos de los servicios que típicamente proporcionan son:

  • Creación de repositorios. Creación del esqueleto de un repositorio sin información inicial del proyecto.
  • Clonación de repositorios. La clonación crea un nuevo repositorio y vuelca la información de algún otro repositorio ya existente. Crea una réplica.
  • Descarga de la información del repositorio principal al local. Sincroniza la copia local con la información disponible en el repositorio principal.
  • Carga de información al repositorio principal desde el local. Actualiza los cambios realizados en la copia local en el repositorio principal.
  • Gestión de conflictos. En ocasiones, los cambios que se desean consolidar en el repositorio principal entran en conflicto con otros cambios que hayan sido subidos por algún otro desarrollador. Cuando se da esta situación, las herramientas de control de versiones tratan de combinar automáticamente todos los cambios. Si no es posible sin pérdida de información, muestra al programador los conflictos acontecidos para que sea éste el que tome la decisión de como combinarlos.
  • Gestión de ramas. Creación, eliminación , integración de diferencias entre ramas, selección de la rama de trabajo.
  • Información sobre registro de actualizaciones.
  • Comparativa de versiones. Genera información sobre las diferencias entre versiones del proyecto.

Las órdenes que se pueden ejecutar son:

  • checkout: obtiene un copia del trabajo para poder trabajar con ella.
  • Update: actualiza la copia con cambios recientes en el repositorio.
  • Commit: almacena la copia modificada en el repositorio.
  • Abort: abandona los cambios en la copia de trabajo.