Este documento pretende hacer una breve introducción al uso de subversion como desarrollador, es decir, trabajar con la copia del repositorio y aplicarle modificaciones. Incluye también una guía paso a paso de las órdenes más habituales en una sesión de trabajo con subversion.

Visión general

Lo primero que tenemos que hacer es conseguir la copia actual del repositorio. Para ello utilizamos el comando "checkout", o su abreviación "co":

svn co http://ruta.al.repositorio.net/proyecto directorio/

Pueden pasar dos cosas: si todo el mundo puede leer el proyecto, éste se bajará sin problemas, pero si hay que estar autenticado, te pedirá tu nombre de usuario y contraseña de acceso para descargar el repositorio.

Si no especificamos el directorio lo descargará en una carpeta con el nombre del proyecto

Ahora ya tenemos una copia activa de nuestro proyecto. Ahora iremos modificando los archivos y haciéndoles las modificaciones que queramos. Una nota muy importante: los archivos y directorios no se pueden añadir y borra directamente (con cp, mv o similares). Eso sólo haría que los cambios fuesen visibles en nuestro directorio, pero al hacer un "commit", orden para aplicar los cambios, éstos no tendrán efecto y al hacer el "checkout" volveríamos a bajar el archivo borrado.

Si queremos variar alguna cosa del repositorio lo tenemos que hacer a través del svn. Las órdenes de svn que tendremos que utilizar son las siguientes, que paso a enumerar con una breve descripción:
 

1. update: Actualiza nuestra copia => svn update
2. add : añade el archivo que se indica al repositorio => svn add fichero
3. delete: borra el archivo que se indica del repositorio => svn delete fichero
4. copy: copia el archivo que queremos con otro nombre => svn copy fichero_original fichero_nuevo
5. move: mueve y renombra el archivo especificado => svn move ffichero_original fichero_nuevo
6. commit: aplica los cambios en el respositorio (si tienes permisos de escritura) => svn commit

Hay que decir que estos parámetros en algunos casos tienen abreviaciones, que son más fáciles de utilizar. Para  verlos 'svn help'.

Es una buena práctica efectuar 'svn status' antes de hacer un commit, ya que nos indicará qué es lo que ha cambiado en nuestra copia respecto al repositorio. Hay diversos indicadores que nos pueden salir al lado del archivo especificado:

• A: El fichero, directorio o enlace simbólico será añadido al repositorio.
• C: El archivo presenta un conflicto. Esto ocurre cuando otro programador ha hecho cambios mientras nosotros modificábamos nuestra copia local y se superponen con la nueva copia. Hay que resolver el conflicto antes de actualizar el repositorio.(razón para actualizar constantemente nuestra copia local)
• D: El fichero, directorio o enlace simbólico será eliminado del repositorio.
• M: Los contenidos del archivo han sido modificados.i
• X: El directorio no tiene versión (mirar en "External Definitions" de la guía oficial).
• ?: El fichero, directorio o enlace simbólico no está bajo ninguna versión.
• !: El fichero, directorio o enlace simbólico está en la versión de control del repositorio pero no se encuentra o está de alguna manera incompleto. Esto puede ocurrir por ejemplo cuando se borra un archivo a mano, sin utilizar subversion, o debido a un checkout incompleto.
• ~: El fichero, directorio o enlace simbólico está en el repositorio como un tipo de objeto, pero lo que hay en tu copia de trabajo es diferente. Por ehemplo, si borras un archivo y creas un directorio con el mismo nombre.
• I: Subversion "ignora" el archivo, directorio o enlace simbólico, probablemente poque tú se lo has dicho.

Con "svn status" podemos saber incluso quién ha hecho las actualizaciones de los archivos que han cambiado con "svn status --verbose".

Si lo que queremos es ver qué cambios hemos aplicado, podemos verlo con "svn diff", que mostrará las diferencias que hemos hecho a cada archivo. Esto también va bien para crear patchs: "svn diff > patch".

Si, por último, hemos hecho un cambio a un fichero y queremos devolverlo a su estado original, lo podemos hacer con "svn revert fichero", o a todo el repositorio si lo hacemos sin argumento "svn revert".

Cuando hacemos un update y luego un status, puede ocurrir que veamos un archivo marcado con una "C", que indicaría que la modificación que se ha efectuado sobre el repositorio y en nuestra copia local no coinciden. Cuando pasa esto, subversion indica dentro de tu archivo donde están los conflictos y se crean tres archivos:

1. archivo.mine: Archivo que teníamos en la copia local en el momento de hacer el update.
2. archivo.rOLDREV: Copia del archivo que teníamos en base en el momento de comenzar a trabajar con el archivo.
3. archivo.rNEWREV: Nueva versión que hay en el repositorio.

* OLDREV y NEWREV son los números de la revisión a la que pertenecen las copias.

Subversion no te dejará hacer un "commit" hasta que no borres estos tres archivos temporales.

Hay 3 tres maneras de resolver el conflicto: Mezclar los dos ficheros a mano, copiar una de las dos copias de versión sobre la tuya o hacer un "revert" del archivo para deshacer todos tus cambios. Una vez has tomado una de estas acciones, sólo tienes que escribir "svn resolved fichero" para indicar a subversion que has resuelto el conflicto.

Ciclo de trabajo habitual

En general, una sesión de trabajo en el repositorio iría así:

1. Checkout (creación de la copia de trabajo local):
   svn co http://ruta.al.repositorio.net/proyecto dir_local/
2. Nos colocamos en el directorio de la copia de trabajo. Modificamos los ficheros que haga falta.
   • Si tenemos que añadir un nuevo fichero (que ya tenemos) al repositorio:
     cp /usr/local/fichero.c .
     svn add fichero.c
   • Si tenemos que modificar la estructura de directorios:
     svn mkdir nuevo_directorio
     svn mv dir_antiguo dir_nuevo
   • Si tenemos que eliminar un fichero o directorio:
     svn delete fichero
   • Si nos equivocamos y queremos volver a la versión activa de parte del repositorio:
     svn revert directorio
3. Miramos qué ha cambiado del repositorio mientras hemos estado trabajando:
   svn update
4. Resolvemos los posibles conflictos que pueda haber entre los archivos locales y el trabajo de otros desarrolladores (marcado con C cuando hacemos el update), hablando con ellos y consensuando los cambios. Hecho esto, escribimos:
   svn resolved archivo.c
5. Miramos qué cambios introduciremos en el repositorio si hacemos un "commit":
   svn status
   svn diff
6. Actualizamos el repositorio con nuestros cambios (si tenemos permisos para hacerlo):
   svn commit fichero -m "Cambio realizado"

Procedimiento habitual de trabajo con svn

• Los programadores ponen todo el trabajo nuevo en el trunk. Los cambios diarios se envían a /trunk: nuevas características, corrección de errores, etc.
• El trunk se copia a una rama de "lanzamiento". Cuando el equipo piensa que el código está listo para lanzarlo (digamos una versión 1.0), entonces copian el /trunk a /branches/1.0.
• Los equipos continúan trabajando en paralelo. Un equipo comienza una comprobación rigurosa de la rama de lanzamiento, mientras otro equipo continúa haciendo trabajo nuevo (para la versión 2.0) en /trunk. SiSi se encuentran bugs en uno u otro lugar, las correcciones se llevan de un sitio a otro según sea necesario. Pero llega un momento en que este proceso se detiene. La rama se "congela" para hacer una comprobación final antes del lanzamiento.
• La rama se marca y se distribuye. Cuando la comprobación se acaba, /branches/1.0 se copia a /tags/1.0.0 como instantánea de referencia. Ahora podemos empaquetar la marca y distribuirla a los clientes.
• La rama se mantiene durante el tiempo. Mientras continúa el trabajo en el /trunk para la versión 2.0, la corrección de errores se continúa llevando del /trunk hacia /branches/1.0. Cuando se han acumuladosuficientes correcciones, podemos decidir hacer una versión 1.0.1: /branches/1.0 se copia a /tags/1.0.1 y la marca se empaqueta y distribuye.
• El proceso entero se repite a medida que el código madura: cuando el trabajo para la 2.0 se termina, se crea una nueva rama 2.0, se comprueba y eventualmente se distribuye. Al cabo de los años el repositorio acaba con un número de ramas de lanzamiento en modo de "mantenimiento", y con un número de "tags" representando versiones finales distribuidas.

(extraído de http://www.milnou.net/~amanya/blog/ y traducido a castellano)