Nota: Para los ejemplos se usará el programa svn en línea de comandos. Los programas gráficos tienen funciones equivalentes, pero pulsando un botoncejo en vez de con una órden del sistema

Pero, ¿que es esta mierda?

Subversion (SVN) es un repositorio de código que permite que varios programadores modifiquen partes distintas en local, y después suban sus cambios al servidor para que cualquiera pueda verlos.

Todas las modificaciones llevan un número de revisión autoincremental, que permite deshacer los cambios sobre un fichero y recuperarlo tal cual estaba en determinada versión.

Al contrario que otros sistemas similares, SVN permite que varias personas modifique a la vez el mismo archivo. Cuando esto pasa, se produce un conflicto que hay que resolver manualmente.

Es importante darse cuenta de que SVN trabaja con diferencias de ficheros. Esto es, cuando actualizas los archivos no se baja los ficheros completos si no es necesario, si no que se baja los cambios y los aplica a la copia actual. Y al contrario, al subir los cambios al servidor se envía un diff entre el archivo que te bajaste y el que has modificado.

Empezando

Antes de nada

Todas las operaciones se harán con el programa svn. El comando mágico cuando no se sepa que hacer es svn help, que muestra un resumen de los comandos y una breve descripción de que hace dada uno.

Los comandos más habituales tiene alias cortos, que son lo que se muestra entre paréntesis. Por ejemplo, es lo mismo hacer svn help que svn h.

Obteniendo el código

Lo primero que hay que hacer es obtener una copia completa del código almacenado en el servidor. A esta operación se la denomina check out.

Para hacerlo con nuestro repositorio tan solo hay que lanzar el comando siguiente desde la carpeta donde se quiere almacenar:

svn checkout http://svn6.assembla.com/svn/ASF

Esto descargará la última versión del servidor y dejará la copia local lista para empezar a trabajar.

Estructura de directorios

En el directorio raiz se habrán descargado 3 carpetas principales:

trunk: Contiene la última copia del código fuente disponible para todo el mundo. Cuando alguien quiere bajarse el código para compilar y usar, se descarga esta carpeta. Puede ser la única carpeta en algunos proyectos sencillos.
tags: Aquí se guardan las distintas versiones del programa. Cada vez que se hacen cambios gordos, se guarda una copia, generalmente con el nombre de la versión. Por ejemplo 2.0.1. >Es importante diferenciar bien el concepto de revisón y el de versión. Una revisión en es el número incremental con el que SVN identifica cada uno de los cambios que se hacen en el árbol de desarrollo, y no está en absoluto relacionado con el sistema de versionado que el desarrollador (o desarrolladores) apliquen de forma más o menos manual. Es decir, cuando una aplicación se encuentra en la revisión 1115 puede estar en la versión 2.0.1, pero eso no implica que al subir a la revisión 1116, sea obligatorio subir la versión a 2.0.2, ni que de algún modo, se haga automáticamente. Eso queda al total albedrío del programador.
branches: Aquí se crean las ramas de desarrollo. Una rama puede ser la implementación de una nueva funcionalidad o un correctivo. Una vez completado el trabajo sobre una rama, se copian los cambios a la copia en trunk.

Nótese que además del código fuente, se habrán generado una serie de carpetas ocultas llamadas .svn. Dentro están todos los metadatos que permiten saber si se ha modificado el fichero, si se debe subir al servidor, etc. No es recomendable modificar su contenido manualmente.

Para extraer los ficheros sin los directorios .svn (por ejemplo, para guardar una copia de seguridad o construir un entregable), se debe hacer una exportación. Es muy sencillo de realizar con el siguiente comando:

svn export <directorio_destino>

Copiará todo el contenido del directorio donde se ejecute a <directorio-destino>, ¡pero sin los fastidiosos directorios .svn!

Trabajando con SVN

Editando la copia local

Una vez descargada la copia local para empezar a editar el código no hay que hacer nada más, sencillamente se empieza a modificar. Eso si, es recomendable actualizar los cambios del servidor en la copia local cada poco tiempo, para no trabajar sobre una copia antígua del código fuente.

Actualizando con los cambios del servidor

Para actualizar los cambios del servidor a la copia local hay que ejecutar dento del directorio raiz de la copia local lo siguiente:

svn update

Subiendo los cambios

Una vez que se han hecho los cambios y la modificación es estable y compila (esto no es necesario, pero igual tus compañeros te cortan un poco los huevos), se pueden subir al servidor con el siguiente comando:

svn commit

Esta acción pedirá que se escriba una breve descripción de lo que se ha modificado en el archivo. Es opcional, y se puede dejar vacío, pero es realmente útil para poder hacer un seguimiento de los cambios.

Una vez completado, los cambios estarán disponibles para todos los usuarios del servidor.

Añadiendo ficheros nuevos

SVN no envía al servidor ficheros nuevos creados dentro de la copia local, lo cual está muy bien, porque te permite tener ficheros de configuración o de pruebas que no se subirán al servidor. Los ficheros nuevos se tienen que añadir explicitamente con el siguiente comando:

svn add <nombre_fichero>

Se pueden usar comodines para elegir varios ficheros. Una vez añadido, se subirán en el próximo svn commit.

Eliminando ficheros

De forma similar a como se añade se pueden eliminar

svn delete <nombre_fichero>

También habrá que hacer svn commit para confirmar los cambios.

Resolviendo conflictos

Un conflicto es cuando dos personas han modificado el mismo archivo a la vez. En ese caso hay que resolver el conflicto a mano. SVN creará dos ficheros de conflicto, cada uno con sus cambios y con el número de revisión de cada uno como subfijo, para poder identificarlos.

Nota: La manera que conozco de solventar conflictos quizás no sea la más sofisticada, pero funciona y como es la única que me se, es la que voy a plasmar.

En caso den encontrar un conflicto habría que seguir los siguientes pasos:

Hacer un svn update para bajar la última copia del servidor
Copiar a mano sobre el fichero recien actualizado los cambios que se quieran aplicar, o bien utilizar una herramienta de diff (como KDiff3)
Hacer commit del fichero recien modificado y borrar los de conflicto.

Para evitar conflictos se recomienda hacer svn update de forma regular, sobre todo antes de empezar a modificar un fichero.

Ejemplo de uso típico

Veamos como se trabajaría normalmente con SVN, creando un proyecto desde cero:

Lo primero que hay que hacer es crear la copia de trabajo local (working copy) mediante el siguiente comando: svn commit http://svn6.assembla.com/svn/ASF
Se crear los ficheros que vaya a contener el proyecto y se añaden con: svn add
Se suben al servidor: svn commit
Antes de modificar archivos, es buena idea comprobar si alguien ha subido cambios: svn update
Una vez hechos cambios, se suben al servidor svn commit

SVN avanzado (pero poco)

Modo pro

Una buena forma de trabajar con estos sistemas es el denominado nightly builds. Consiste en, antes de irte a casa, comprobar que los cambios que has hecho compilan y funcionan, y subirlos al servidor. Buena idea por si te pones malo o te vas de vacaciones, así no dejas las cosas a mitad.

Además y de propina, cada vez que haces commit, se guarda una copia en el servidor, a la que puedes acudir en caso de desastre. Por lo tanto funciona como un sistema de copias de seguridad.

Modo master del universo

Tener la disciplina de subir los cambios al final de la jornada está muy bien, pero siempre puede escaparse un error que, si alguien se bajase el código del trunk, podría producirle problemas. Para ello se puede utilizar el sistema de ramas de desarrollo (branches).

Esto consiste en hacer una copia de todo el directorio trunk en una subcarpeta de branches. Sobre esta copia se harán los cambios pertinentes y, una vez hechos y probados, se copiarán de vuelta al directorio trunk. Esto permite mantener la rama de desarrollo todo lo en guarrinada que sea necesario, y aplicar los cambios sólo cuando estén completos y funcionen. De esta manera el trunk siempre tiene la última versión estable.

Aplicar los cambios de una rama al trunk sería crear una nueva versión del programa. Si los cambios son moderados será una versión menor, y si son grandes será un cambio de versión mayor.

Para llevar un seguimiento de las distintas versiones del programa, es recomendable guardar una copia del trunk en el directorio tags cada vez que se apliquen los cambios realizados en una rama, sobre el trunk.

Ahora veamos como se haría todo esto paso por paso.

Para crear una nueva rama:

svn copy ^/trunk ^/branches/nombre_rama
svn commit
svn update

Esto creará una nueva rama y confirmará cambios y actualizará todo. En resumen, creará una nueva rama lista para trabajar sobre ella. Sobre este nuevo directorio se realizarán todos los cambios, se harán los commit que se quieran (recomendable hacerlos cada poco tiempo, para tener una copia de seguridad en el servidor) y se dejará todo listo y preparado.

Una vez completadas las modificaciones previstas, y comprobado que funcionan bien, es la hora de volcar los cambios sobre el trunk. Para ello, desde el directorio raiz de la rama se ejecuta el siguiente comando:

svn merge ^/trunk

Después de la operación sería buena idea hacer un svn update del directorio raiz (working copy) y comprobar que el trunk compila y muestra correctamente los cambios.

Una vez que estamos seguros de que el merge ha ido bien, es buena idea guardar una copia de la nueva versión en tags. El proceso es similar a crear una nueva rama, solo que se usa el directorio tags en vez de branches:

svn copy ^/trunk ^/tags/version.nueva
svn commit
svn update

Y eso es todo (que no es poco)

Más información

Para más información, se puede consultar la siguiente página: http://svnbook.red-bean.com/