Control de versiones: Mecanismos de control de versiones

Repositorios. Gestión y administración.

Los repositorios son los lugares donde se guardan las versiones (tanto actuales como antiguas) de nuestras aplicaciones, a menudo un servidor. A veces se les denomina depósito o depot. Puede ser un sistema de archivos en un disco duro, un banco de datos, etc...

Publicación de cambios (<<check-in>> o <<commit>>). Operaciones atómicas.

El commit consiste en integrar o escribir una copia de los cambios hechos a una copia local sobre un repositorio.
Un commit atómico consiste en realizar un commit cargando a la fuente cambios en varios ficheros (llamado changeset) mientras garantizan que todos los ficheros se cargan completamente y se combinan. Si hay un fallo que imposibilite el completar la transacción, el commit es abortado y todos los cambios que han tenido lugar son revertidos.
En un commit atómico, normalmente los ficheros a los que se les hace commit juntos se tratan con una modificación individual, y todo lo cambiado en esta modificación debe ser incluido en el commit.
De esta manera, el tronco del código permanece estable; las personas que actualizan su copia no pierden cambios dejados para ser commited en la copia de alguien más; el changeset no es demasiado sucio para poder leer en el; y si el commit atómico es revertido, la modificación individual es eliminada enteramente de todas las partes de la base del código.

Tipos de desprotección, despliegue o <<check-out>>.

Un despliegue crea una copia de trabajo local desde el repositorio. Se puede especificar una revisión concreta, y por defecto se suele obtener la última.

Ramificaciones(<<branching>>)

Las ramificaciones son un proceso que consiste en ramificar o bifurcar un módulo. A partir de ese momento, el módulo tendrá dos o más ramas que evolucionan de forma independiente, consiguiendo su propia linea de desarrollo. La ventaja es que se pueden fusionar ambas ramas, creando con ello las denominadas "ramas de prueba" que contienen código para evaluación. Si se dedice que las modificaciones de esta rama de prueba sean preservadas, se fusionan con la rama principal. Los motivos principales de la creación de ramas es la adición de nuevas funcionalidades o la corrección de errores.

Fusiones(<<merging>>)

Una fusión une dos conjuntos de cambios sobre un fichero o un conjunto de ficheros en una revisión unificada de dicho fichero o ficheros. Puede ocurrir por las siguientes causas:
- Puede ocurrir cuando un usuario sobreescribe los ficheros existentes en el repositorio(añadidos por otros usuarios) por los suyos locales con los cambios realizados en ellos. Del mismo modo también puede ocurrir cuando un usuario intenta hacer un commit.
- Puede ocurrir tras hacer una ramificación, y el problema anterior a dicha ramificación sea resuelta en una de las ramas resultantes y se necesite incorporar dicha solución.
- Puede ocurrir tras hacer una ramificación y que las ramas hayan sido desarrolladas independientemente durante un tiempo. Tras ese tiempo se requiere que sean fundidos de nuevo en un tronco unificado.

Etiquetado(<<tagging>>)

Consiste en marcar o etiquetar un momento preciso del desarrollo de un módulo con un nombre común, para asegurarse de poder reencontrar ese estado mediante ese nombre. En la practica se etiqueta a todos los archivos en un momento determinado. Para ello, el módulo se "congela" durante el etiquetado para imponer una versión coherente.
Los tags permiten indentificar de forma fácil revisiones importantes del proyecto.

Líneas de base(<<baseline>>)

Una linea de base es una revisión aprobada de un documento o fichero fuente, a partir del cual se pueden realizar cambios subsiguientes.

Actualizaciones.

Una actualización integra los cambios que han sido hechos en el repositorio (por ejemplo por otras personas) en la copia de trabajo local.

Congelaciones.

Congelar significa permitir los últimos cambios (commits) para solucionar las fallas a resolver en una entrega (release) y suspender cualquier otro cambio antes de una entrega, con el fin de obtener una versión consistente. Si no se congela el repositorio, un desarrollador podría comenzar a resolver una falla cuya resolución no está prevista y cuya solución dé lugar a efectos colaterales imprevistos.

Gestión de conflictos.

Un conflicto ocurre cuando se dan las siguientes circunstancias:
Dos usuarios despliegan el mismo archivo. El primero de ellos envía cambios en una parte determinada del archivo. El segundo usuario no actualiza su versión del archivo y envía nuevos cambios en la misma parte. El sistema es incapaz de fusionar los cambios.
El segundo usuario debe resolver el conflicto combinando los cambios o eligiendo uno de ellos para descartar el otro.