PDF de programación - Sistemas de control de Versiones

Sistemas de Control de Versiones

Sebastián Viviani

[email protected]

Abril de 2010

“La vida, por corta que parezca,da

tiempo para todo”(A.Bioy Casares)

Resumen

El presente documento tiene como objetivo explicar en que consiste un Sistema de Control
de Versiones, qué usos se le puede dar, el procedimiento y los requerimientos para acceder
y utilizar el mismo, y los comandos y funciones básicas que se pueden realizar (modificar
un proyecto, generar un nuevo proyecto, controlar el historial de cambios, ver los proyectos
existentes, etc).

Este tutorial se basará en un sistema en especial, el subversion, de uso bastante di-
fundido en ambientes de desarrollo de software académicos y profesionales. No obstante, las
nociones básicas son aplicables a otros sistemas que manejen la misma filosofía, como el
también popular cvs

1. Filosofía del sistema

En cualquier proyecto de desarrollo de software, es común que haya más de un desar-
rollador involucrado. Incluso en la codificación de sistemas pequeños, como puede ser el
firmware de un microcontrolor de 8 bits, o una aplicación que correrá en un sistema embed-
ded. Ya sea para programar el código, para controlar y validar el avance del mismo, para
revisarlo, etc.

Y es lógico que cada desarrollador trabaje en su propia computadora, por un tema de
performance (no suena muy práctico que se vayan turnando para utilizar el teclado y el
monitor).

Es necesario, por lo tanto, encontrar una forma de poder ”compartir” los archivos de
código fuente, evitando las limitaciones físicas conocidas y los posibles conflictos al realizar
cambios en los mismos. Normalmente, una arquitectura modular, bien diseñada, es solución
suficiente para asegurarse que los programadores puedan trabajar en diferentes módulos (o
archivos), sin pisar su trabajo entre ellos. Y un File Server central, donde se almacene el
código, un método sencillo de que todos tengan acceso al proyecto completo.

Esta aproximación, bastante simple y rústica, es ampliamente utilizada en pequeñas,
medianas y grandes empresas, con relativo éxito. Pero tiene severas limitaciones, empezando
por la performance (pensar que TODOS los desarrolladores estarán accediendo al código a
través de la LAN), la ”ortogonalidad” del trabajo de cada uno está sujeta a la buena voluntad
de cada miembro, y es dificil rastrear los cambios realizados. Sin mencionar que limita a que
cada desarrollador, para poder trabajar tenga que tener acceso a la LAN, aunque sea remoto,
pero de forma permanente.

Existen sistemas de control de versiones que trabajan con ese enfoque, y agregan ciertas
funcionalidades, como el SourceSafe o el PVCS (no confundir con el CVS). En general, la
vuelta de tuerca que agiliza y soluciona parcialmente los problemas es que el usuario trabaja
sobre una copia local, que se copia cuando la ”pide” al servidor (operación de lock). Este
lleva un registro de los archivos ”pedidos”, y no permite que dos personas trabajen en el
mismo archivo, además de advertir a un usuario cuando pide un archivo que depende de
otro que ya está pedido (es decir, depende de algo que probablemente cambie).

1

Ahora, casi como un ejercicio de pensamiento lateral, hay que plantear otro forma de
atacar el problema. Se va a mantener el almacenamiento centralizado del código fuente, en
un servidor remoto, al que llamaremos repositorio.

Cada desarrollador tendrá una copia completa del proyecto, en el disco local de su com-
putadora, que deberá sincronizar periodicamente con el repositorio. A esta operación de
sincronizar la copia, la llamaremos operación de update.

Sobre su copia local, podrá hacer todos los cambios que quiera, a todos los archivos
que quiera. Dispone de total libertad para trabajar con ellos. Periodicamente, cuando tenga
partes del código listas y probadas, que deban incluirse en el proyecto reportará los cambios
al repositorio, transmitiendo solamente las diferencias entre este y su copia local. Y lo más
importante, en cada reporte indicará de forma clara y amplia, que cambios realizó y porque.
A esta operación de reportar los cambios, la llamaremos operación de commit.

Si miramos ahora el cuadro completo, vemos que este nuevo enfoque es mucho más
eficiente, práctico y flexible. Los desarrolladores solo necesitan conectarse al repositorio
para actualizar o reportar cambios, tienen la libertad de explorar y modificar el código para
rastrear bugs o encontrar mejoras, y se lleva un registro claro de quien modificó cada parte
del proyecto, y cuándo lo hizo.

Al trabajar en una copia local, casi que no se debe luchar contra anchos de banda ni
throughputs, y un backup periódico del server, o un mirror, ayuda a ganar en confiabilidad
y seguridad al sistema. Obviamente, surgen aspectos de seguridad informática a tener en
cuenta, y otros temas que se verán más adelante en lo que respecta a la operación, pero las
ventajas son evidentes.

Esta filosofia es la que emplea el subversion, y fue implementada originalmente por el

cvs (del inglés Concurrent Version System).

Esta forma de trabajar tiene un problema, y es el que se da cuando dos (o más) usuarios
realizan cambios en el mismo archivo, y tratan de reportarlos. El sistema detecta estos casos,
y normalmente resuelve los conflicos de forma automática (puede ser que realicen cambios
en diferentes partes del mismo archivo, sin que esto sea un conflicto).

Y en los casos donde hay una porción común de código involucrada, deja a criterio del
último en reportar que hacer, si pisar los cambios o no. Esta operación se llama merge.
Estos conflicos se evitan normalmente si el usuario tiene la precaución de realizar updates
antes de comenzar a trabajar en el código, para asegurarse de que arranca con una versión
actualizada.

IMPORTANTE:
La resolución de conflictos se realiza asumiendo que los archivos son de texto plano!
La reacción del sistema ante conflictos en archivos binarios es impredecible, asi que
no se recomienda incluirlos con los archivos de cógido fuente del proyecto.

2. Requerimientos

2.1. Repositorio

El repositorio es básicamente un directorio, que se accede por medio de una url. Como
todo servicio, tiene un port asignado, el 3690, que se usará en caso de que la url sea de la
forma

svn://direccion-repositorio:/proyecto
El acceso también puede configurarse por medio de un modulo de un servidor web, como
el popular apache. En ese caso, se utilizan el port 80 normal, y se puede aprovechar para
encriptar la conexión (y por ende, proteger la información transmitida) con el protocolo
https.

El repositorio se organiza en directorios, y los permisos de cada directorio son similares
a los del filesystem de Unix. Se pueden agrupar por proyectos, por usuarios, etc, según el
criterio del administrador.

Es importante (y aunque suene un poco trivial, no está de más la aclaración) resaltar
que si el repositorio está en una LAN, y debe ser accesible desde internet, el port corre-
spondiente en el Gateway debe estar redireccionado a la IP local del server.

2

En este documento no se analizará como instalar y/o configurar un repositorio. Queda

a cargo del lector, si está interesado, googlear el tema.

2.2. Clientes

Un cliente svn es una aplicación que se conecta al repositorio, y actua sobre un directorio
local. Esta aplicación es la que ejecuta los diferentes comandos del protocolo, que incluyen los
ya mencionados update y commit, además de otros útiles para ver el contenido del repos-
itorio, de sus directorios, generar nuevos, ver el número de revisión, el historial, comparar
versiones, agregar o quitar archivos, etc.

Normalmente, se genera un subdirectorio oculto, llamado SVN o .svn en el directorio
local. Este subdirectorio contiene información que utiliza el subversion, y no debe ser
alterado manualmente por el usuario.

El cliente más simple, sobre el que se darán los ejemplos de este documento, se ejecuta
por línea de comandos. Aunque no es el único disponible. Actualmente también hay ver-
siones más amigables al usuario, que se integran al WindowsTMExplorer o a los diferentes
Window Managers de Linux. Incluso muchos IDE’s tienen plugins que permiten sincronizar
directamente el proyecto actual.

En esos casos, suelen configurarse los parámetros desde una ventana, y luego se utilizan
de la misma forma que al ejecutar los procedimientos desde la consola, pero de forma au-
tomática. No debería ser muy dificil que el lector pueda trasladar lo explicado en esta guia
a cada caso particular.

Por lo tanto, para empezar, con asegurarse de que el paquete subversion está instalado,

es suficiente. En las distribuciones Debian, esto se realiza ejecutando

apt-get install subversion

Los usuarios de WindowsTMpueden descargar e instalar el TortoiseSVN, un cliente que

se integra al GUI del sistema.

2.3. Usuarios

Para poder realizar operaciones en el repositorio, primero se debe tener autorización
para hacerlo. La forma de otorgar y controlar el acceso normalmente es por medio de un
username y un password que se utilizan en cada transacción.

Suele existir, en los proyectos open-source que están disponibles en Internet, un usuario
especial, que se llama anonymous. Dicho usuario suele tener sólo permisos de lectura, y su
fin es que se pueda acceder al código para su estudio sin necesidad de estar registrado.

Es responsabilidad del administrador del repositorio generar los pares de username
y password de los usuarios que trabajarán, y otorgarle los permisos correctos a cada uno.

3. Operaciones básicas

Una vez que tenemos acceso a un repositorio, a través de una url conocida, con un
username y password autorizados, podemos comenzar a utilizar el svn. Para ver una lista
de comandos, o las opciones específicas de cada uno, podemos ejecutar

svn help

Para todos los ejemplos, supondremos que el repositorio se encuentra en http://www.
electron.frba.utn.edu.ar:8008/td3demo y que los datos de la