PDF de programación - Capítulo 7 - Sistema de control de versiones

Capítulo 7
Sistema de control de versiones

1.- Introducción

Un sistema de control de versiones o SVC (System Version Control) es una herramienta
que registra los cambios realizados sobre un archivo o conjunto de archivos de un proyecto a lo
largo del tiempo, de modo que puedas recuperar la versión de esos archivos en un estado
anterior en el tiempo.

El sistema de control de versiones es de gran utilidad para entornos de desarrollo
colaborativo donde varios disenadores, maquetadores y/o programadores trabajan sobre un
mismo proyecto. En todo momento tenemos los cambios que se realizan sobre cada uno de los
ficheros por los diferentes programadores y podemos recuperar un fichero en un estado anterior.

En este capítulo nos vamos a centrar en la herramientas Git y Subversión, pero existen

muchas otras como CVS, Mercurial, Bazaar, SourceSafe, etc.

2.- Definición y características de los SCV

Es un sistema que registra los cambios realizados sobre un archivo o conjunto de archivos
a lo largo del tiempo, de modo que se pueda recuperar versiones específicas de los mismos en un
determinado momento.

Un SVC posee tres capacidades importantes:

• Reversibilidad: retornar a un estado anterior del proyecto en caso de fallos.
• Concurrencia: Muchas personas modificando el mismo código o documento.
• Anotación: Adjuntar información relevante de los cambios realizados.

Un sistema de control de versiones debe proporcionar:

• Mecanismo de almacenamiento de los elementos que deba gestionar (ej. archivos de

texto, imágenes, documentación...).

• Posibilidad de realizar cambios sobre los elementos almacenados (ej. modificaciones

parciales, añadir, borrar, renombrar o mover elementos).

• Registro histórico de las acciones realizadas con cada elemento o conjunto de elementos

(normalmente pudiendo volver o extraer un estado anterior del producto).

3.- Conceptos Básicos en los Sistemas de control de versiones

Repositorio: lugar en el que se almacenan los datos actualizados e históricos de cambios
(sistema de archivos en un disco duro, un banco de datos, etc).

Revisión: Versión determinada de la información que se gestiona.
Tags: Permiten identificar de forma fácil revisiones importantes en el proyecto.
Módulo: Conjunto de directorios y/o archivos dentro del repositorio que pertenecen a un proyecto
común.
Branch: Es una copia del proyecto aislada, de forma que los cambios realizados no afecten al
resto del proyecto y vice versa, excepto cuando los cambios sean "unidos" de un lado al otro.

Baseline: Una revisión aprobada de un documento o fichero fuente, a partir del cual se pueden
realizar cambios subsiguientes.

Checkout: crea una copia de trabajo local desde el repositorio.

Merge: Une dos grupos de cambios en un archivo (o grupo de archivos), generando una revisión
unificada.
Conflicto: Sucede cuando dos o más personas intentan realizar diferentes cambios en la misma
porción de código.

Commit: Consiste en realizar un cambio local en el proyecto y luego almacenar dicho cambio en
el repositorio.
Change set: Conjunto de cambios realizados en un único commit.

Update: Integra los cambios que han sido realizados en el repositorio en la copia de trabajo local.



4.- Clasificación de los SCV

Podemos clasificar los sistemas de control de versiones según la arquitectura para

almacenar la información en locales, centralizados o distribuidos.

•

Locales: La información se guarda en un ordenador o repositorio local con lo que no sirve
para trabajar en forma colaborativa. Ejemplo: RCS (Revision Control System).

• Centralizados o CVCS (Centralized Version Control System): La información se guarda
en un servidor dentro de un repositorio centralizado. Existe un usuario o usuarios
responsables con capacidad de realizar tareas administrativas a cambio de reducir
flexibilidad, necesitan la aprobación del responsable para realizar acciones, como crear
una rama nueva. Ejemplos: Subversión y CVS.

• Distribuidos o DVCS (Distributed Version Control System): Cada usuario tiene su
propio repositorio. Los distintos repositorios pueden intercambiar y mezclar revisiones
entre ellos. Es frecuente el uso de un repositorio, que está normalmente disponible, que
sirve de punto de sincronización de los distintos repositorios locales. Ejemplos: Git y
Mercurial, Bazaar y Darcs.

5.- Subversión

6.- Instalación y configuración de subversión en modo gráfico Windows

1.- Descargamos el servidor y lo instalamos

http://www.visualsvn.com/server/download/

Aceptamos la licencia:

Instalamos el servidor y la consola:

Instalamos la edición estandar:
Seleccionamos el directorio donde lo instalamos y el directorio del los repositorios:

Comenzamos la instalación:
Permitimos se ejecute el programa de instalación:

Finalizamos el asistente y arrancamos Visual SVN:

Permitimos la ejecución de VisualSVN:

Creamos un nuevo repositorio:
Le damos nombre:

Creamos un repositorio vacío:
Damos permiso de lectura y escritura a todos los usuarios:
Finalizamos la creación:

Creamos un nuevo usuario:
Modificamos los permisos de lectura y escritura del usuario:

Instalamos cliente TortoiseSVN

TortoiseSVN es un cliente subversion con licencia GNU GPL. Se integra al explorador de

Windows y puede incorporar los comandos de subversión. Lo descargamos e instalamos.

SVN Checkout: Primero nos conectamos al servidor.

https://ip/svn/repositorio

Posteriormente:
SVN Update: Descargar repositorio
SVN Commit: Actualizar repositorio

Instalamos Subversión en ubuntu
http://proyectosbeta.net/2013/07/instalar-un-servidor-svn-en-ubuntu-13-04/

Herramienta gráfica cliente SVN para ubuntu
sudo apt-get install rapidsvn

Conceptos Subversión

Repositorio (repository)
Es el almacén donde se guardan todos los ficheros y sus versiones. Todas las operaciones
registran un punto de referencia en el repositorio: por ejemplo, hacer un check-out (extraer un
fichero del repositorio) o un commit (incorporar un
fichero al repositorio).

Copia de trabajo (working copy)
Inicialmente es el directorio que se obtiene al hacer el check-out de un proyecto almacenado en
un repositorio. La copia de trabajo contiene información para que Subversion pueda saber qué
ficheros están sincronizados y cuáles no. Es el directorio donde después de hacer check-out
editaremos nuestros ficheros y los iremos incorporando en el repositorio. La copia de trabajo
también contiene ficheros extras que ayudan a mantener la sincronía con el repositorio y facilitan
la implementación de las órdenes. Estos ficheros de administración se encuentran en la carpeta
.svn, y no se deben borrar.

Directorio para inicializar el repositorio
Es el directorio que contiene los ficheros de la práctica o proyecto que queremos poner bajo
control de revisiones. Si ejecutamos la orden svn import, Subversion incorporará todos los ficheros
al repositorio. IMPORTANTE: Una vez finalizada la importación de ficheros, este directorio no se
convierte en una copia de trabajo. Por lo tanto, para seguir trabajando con los ficheros que
contenía este directorio, necesitaremos ejecutar svn check-out para obtener una copia de trabajo
limpia y ubicada, para mayor seguridad, en un nuevo directorio. Entonces podremos empezar a
modificar el código de la práctica que hay en el directorio donde se ha hecho el check-out. El
directorio que hemos usado para
inicializar el repositorio se puede borrar.

Sincronización
Es la clave para realizar el control de versiones. Debe ser nuestro objetivo en todo momento: tener
un repositorio y una copia de trabajo en sincronía. Si partimos de una copia de trabajo
sincronizada, nos pueden pasar dos cosas:

1. La copia de trabajo se ha modificado y no está sincronizada con el repositorio.

2. El repositorio ha sido actualizado por otro miembro del grupo de trabajo, en el caso
de que haya un grupo de programadores, y el repositorio no está sincronizado con la
copia de trabajo.

Para conseguir la sincronía en cada una de las dos situaciones anteriores, habrá que ejecutar:

1.svn commit, para actualizar el repositorio.

2.svn update, para descargarnos los cambios a nuestra copia de trabajo.

Ciclo habitual de trabajo
Podemos ver el ciclo habitual de trabajo en el siguiente gráfico que explicaremos a continuación:


• Estado 1
No existe ni un repositorio ni una copia de trabajo. En este punto, podemos ejecutar la
orden svn create para crear un repositorio.



svn create

• Estado 2
D i s p o n e m o s d e u n r e p o s i t o r i o , p e r o e s t á v a c í o . C o n

l a o r d e n

svn import

cargamos el repositorio con los ficheros del directorio.

• Estado 3
Disponemos de un repositorio con datos, pero todavía no podemos modificar sus
ficheros. Hay que crear la copia de trabajo:

svn checkout

• Estado 4
El repositorio contiene datos y existe una copia de trabajo sincronizada. Ahora
podemos modificar nuestra copia de trabajo:

• Modificamos ficheros con un editor de texto, o
• Añadimos, borramos, copiamos o renombramos ficheros:

• svn add
• svn delete
• svn copy
• svn move

• Estado 5
Tenemos una copia de trabajo modificada con respecto al repositorio. Ahora
n e c e s i t a m o s g u a r d a r
r e p o s i t o r i o :

l o s c a m b i o s e n e l

svn commit

Con esta operación volvemos al estado 4.

• Estado 6 se puede llegar a este estado cuando se trabaja en grupo sobre un repositorio, y
alguien lo modifica. En este caso, tendremos que incorporar estos cambios a nuestra copia
de trabajo. Ejecutamos la orden:
svn update

Con esta operación volvemos al estado 4.

En cualquier momento del desarrollo podemos consultar las diferencias entre el r