Control de versiones con Subversion

Subversion es un sistema de control de versiones libre y de código fuente abierto. Es decir, Subversion maneja ficheros y directorios a través del tiempo. Hay un árbol de ficheros en un repositorio central. El repositorio es como un servidor de ficheros ordinario, excepto porque recuerda todos los cambios hechos a sus ficheros y directorios. Ésto le permite recuperar versiones antiguas de sus datos, o examinar el historial de cambios de los mismos. En este aspecto, mucha gente piensa en los sistemas de versiones como en una especie de “máquina del tiempo ”.

Subversion puede acceder al repositorio a través de redes, lo que le permite ser usado por personas que se encuentran en distintos ordenadores. A cierto nivel, la capacidad para que varias personas puedan modificar y administrar el mismo conjunto de datos desde sus respectivas ubicaciones fomenta la colaboración. Se puede progresar mas rápidamente sin un único conducto por el cual deban pasar todas las modificaciones. Y puesto que el trabajo se encuentra bajo el control de versiones, no hay razón para temer por que la calidad del mismo vaya a verse afectada por la pérdida de ese conducto único—si se ha hecho un cambio incorrecto a los datos, simplemente deshaga ese cambio.

Algunos sistemas de control de versiones son también sistemas de administración de configuración de software. Estos sistemas son diseñados específicamente para la administración de árboles de código fuente, y tienen muchas características que son específicas del desarrollo de software— tales como el entendimiento nativo de lenguajes de programación, o el suministro de herramientas para la construcción de software. Sin embargo, Subversion no es uno de estos sistemas. Subversion es un sistema general que puede ser usado para administrar cualquier conjunto de ficheros. Para usted, esos ficheros pueden ser código fuente— para otros, cualquier cosa desde la lista de la compra de comestibles hasta combinaciones de vídeo digital y más allá.

A principios del 2000, CollabNet, Inc. (http://www.collab.net) comenzó a buscar desarrolladores para escribir un sustituto para CVS. CollabNet ofrece un conjunto de herramientas de software colaborativo llamado SourceCast, del cual un componente es el control de versiones. Aunque SourceCast usaba CVS como su sistema de control de versiones inicial, las limitaciones de CVS se hicieron evidentes desde el principio, y CollabNet sabía que tendría que encontrar algo mejor. Desafortunadamente, CVS se había convertido en el estándar de facto en el mundo del código abierto porque no había nada mejor, al menos no bajo una licencia libre. Así CollabNet decidió escribir un nuevo sistema de control de versiones desde cero, manteniendo las ideas básicas de CVS, pero sin sus fallos y defectos.

En febrero del 2000, contactaron con Karl Fogel, autor de Open Source Development with CVS (Coriolis, 1999), y le preguntaron si le gustaría trabajar en este nuevo proyecto. Casualmente, por aquel entonces Karl ya se encontraba discutiendo sobre el diseño de un nuevo sistema de control de versiones con su amigo Jim Blandy. En 1995, los dos habían fundado Cyclic Software, compañía que hacía contratos de soporte de CVS, y aunque después vendieron el negocio, seguían usando CVS todos los días en sus trabajos. La frustración de ambos con CVS había conducido a Jim a pensar cuidadosamente acerca de mejores vías para administrar datos versionados , y no sólo tenía ya el nombre de “Subversion”, sino también el diseño básico del repositorio de Subversion. Cuando CollabNet llamó, Karl aceptó inmediatamente trabajar en el proyecto, y Jim consiguió que su empresa, RedHat Software, básicamente lo donara al proyecto por un período de tiempo indefinido. Collabnet contrató a Karl y a Ben Collins-Sussman, y el trabajo detallado de diseño comenzó en mayo. Con la ayuda de algunos ajustes bien colocados de Brian Behlendorf y Jason Robbins de CollabNet, y Greg Stein (por aquel entonces un activo desarrollador independiente del proceso de especificación de WebDAV/DeltaV), Subversion atrajo rápidamente a una comunidad activa de desarrolladores. Ésto vino a demostrar que era mucha la gente que había tenido las mismas frustrantes experiencias con CVS, y que había recibido con agrado la oportunidad de hacer algo al respecto.

El equipo de diseño original estableció algunos objetivos simples. No querían abrir nuevos caminos en la metodología del control de versiones, sólo querían corregir CVS. Decidieron que Subversion incorporaría las características de CVS, y que preservarían el mismo modelo de desarrollo, pero sin duplicar los defectos obvios de CVS. Y aunque no necesitaba ser un reemplazo exacto de CVS, debía ser lo bastante similar para que cualquier usuario de CVS pudiera hacer el cambio con poco esfuerzo.

Después de catorce meses de codificación, Subversion pasó a ser “auto-hospedado” el 31 de agosto del 2001. Es decir, los desarrolladores de Subversion dejaron de usar CVS para la administración del propio código fuente de Subversion, y en su lugar empezaron a usar Subversion.

Si bien fue CollabNet quien inició el proyecto, y todavía financia una gran parte del trabajo (paga el salario de unos pocos desarrolladores a tiempo completo de Subversion), Subversion funciona como la mayoría de proyectos de código abierto, dirigido por un conjunto informal de reglas transparentes que fomentan el mérito. La licencia copyright de CollabNet es completamente compatible con las Directrices de Software Libre de Debian. En otras palabras, cualquier persona es libre de descargar, modificar, y redistribuir Subversion como desee; no se requiere ningún permiso de CollabNet o de cualquier otra persona.

Al discutir acerca de las características que Subversion aporta al mundo del control de versiones, a menudo es útil hablar de ellas en términos de cómo han mejorado sobre el diseño de CVS. Si no está familiarizado con CVS, quizás no entienda todas estas características. Y si no está familiarizado con el control de versiones en absoluto, se le pueden nublar los ojos a menos que lea primero Capítulo 2, Conceptos básicos, donde proporcionamos una leve introducción al control de versiones en general.

Subversion proporciona:

Figura 1.1, “Arquitectura de Subversion” ilustra lo que uno podría titular una visión panorámica del diseño de Subversion.

Figura 1.1. Arquitectura de Subversion

En un extremo se encuentra un repositorio de Subversion que conserva todos los datos versionados. Al otro lado, hay un programa cliente Subversion que administra réplicas parciales de esos datos versionados (llamadas “copias de trabajo”). Entre estos extremos hay múltiples rutas a través de varias capas de acceso al repositorio (AR). Algunas de estas rutas incluyen redes de ordenadores y servidores de red que después acceden al repositorio. Otras pasan por alto la red y acceden al repositorio directamente.

Subversion está construido sobre una capa de portabilidad llamada APR (la biblioteca Apache Portable Runtime), lo cual significa que Subversion debería funcionar en cualquier sistema operativo donde lo haga el servidor httpd Apache: Windows, Linux, todos los sabores de BSD, Mac OS X, Netware y otros.

La manera más sencilla de obtener Subversion es descargando un paquete binario construido para su sistema operativo. El sitio web de Subversion (http://subversion.tigris.org) dispone a menudo de estos paquetes disponibles para su descarga, publicados por voluntarios. El sitio web contiene generalmente paquetes que incluyen instaladores gráficos para los usuarios de los sistemas operativos de Microsoft. Si usted usa un sistema operativo Unix o similar, puede usar el sistema nativo de distribución de paquetes de su sistema (RPMs, DEBs, el árbol de ports, etc.) para obtener Subversion.

Alternativamente, usted puede compilar Subversion directamente a partir del código fuente. Del sitio web de Subversion, descargue la ultima versión del código fuente. Después de desempaquetarlo, siga las instrucciones del fichero INSTALL para compilarlo. Observe que cada paquete de código fuente que se publica contiene todo lo necesario para construir un cliente de línea de comandos capaz de comunicarse con un repositorio remoto (en particular, las bibliotecas apr, apr-util y neon). Sin embargo, las partes opcionales de Subversion tienen otras muchas dependencias, tales como la base de datos Berkeley DB y posiblemente el servidor web Apache. Si usted quiere hacer una compilación completa, asegúrese de tener todos los paquetes documentados en el fichero INSTALL. Si planea trabajar en el propio Subversion, puede usar su programa cliente para obtener la última y más reciente versión del código fuente. Este procedimiento está documentado en “Obtenga el código fuente”.

Una vez instalado, Subversion se compone de un número diferente de piezas. A continuación se presenta una visión general de estos componentes. No se alarme si las descripciones breves no le dejan las cosas muy claras —hay páginas de sobra en este libro dedicadas a aliviarle esa confusión.

Suponiendo que ha instalado Subversion correctamente, debería estar preparado para comenzar. Los próximos dos capítulos le guiarán a través del uso de svn, el programa cliente de Subversion de línea de comandos.

Algunas personas tienen problemas para absorber una nueva tecnología leyendo un enfoque del tipo "arriba a abajo" como el que ofrece este libro. Esta sección es una introducción muy breve a Subversion, y está pensada para dar a los principiantes algo con lo que defenderse. Si usted es de los que prefiere aprender experimentando, la siguiente demostración le pondrá en marcha. A lo largo del camino, le iremos dando enlaces a los capítulos relevantes de este libro.

Si a usted le resulta completamente nuevo el concepto de control de versiones o el modelo “copiar-modificar-mezclar” usado tanto por CVS como por Subversion, debería leer Capítulo 2, Conceptos básicos antes de seguir adelante.

Subversion almacena todos los datos versionados en un repositorio central. Para comenzar, cree un nuevo repositorio:

$ svnadmin create /path/to/repos 
$ ls /path/to/repos
conf/  dav/  db/  format  hooks/  locks/  README.txt

Este comando crea un nuevo directorio /path/to/repos que contiene un repositorio de Subversion. Asegúrese de que este directorio reside en un disco local y no compartido en red. Este nuevo directorio contiene principalmente una colección de ficheros de la base de datos Berkeley DB. Para más información sobre la creación y mantenimiento de repositorios, vea Capítulo 5, Administración del Repositorio.

A continuación, cree un árbol de ficheros y directorios para importar dentro del repositorio. Por razones que se aclararán más tarde (vea Capítulo 4, Crear ramas y fusionarlas), su estructura debería tener tres directorios en el primer nivel de la jerarquía llamados branches,tags, y trunk:

/tmp/project/branches/
/tmp/project/tags/
/tmp/project/trunk/
               foo.c
               bar.c
               Makefile
               …

Una vez tenga un árbol de datos listo para continuar, impórtelo dentro del repositorio con el comando svn import (vea “svn import”):

$ svn import /tmp/project file:///path/to/repos -m "initial import"
Adding         /tmp/project/branches
Adding         /tmp/project/tags
Adding         /tmp/project/trunk
Adding         /tmp/project/trunk/foo.c
Adding         /tmp/project/trunk/bar.c
Adding         /tmp/project/trunk/Makefile
…
Committed revision 1.
$ 

Ahora el repositorio contiene este árbol de datos. Observe que el directorio original /tmp/project no se ha modificado; Subversion no se preocupa por él (de hecho, puede incluso borrar ese directorio si lo desea). Para comenzar a manipular los datos del repositorio, necesitará crear una nueva “copia de trabajo” de los datos, una especie de entorno de trabajo privado. Pida a Subversion que “obtenga” ^[5] una copia de trabajo del directorio trunk del repositorio:

$ svn checkout file:///path/to/repos/trunk project
A  project/foo.c
A  project/bar.c
A  project/Makefile
…
Checked out revision 1.

Ahora usted dispone de una copia personal de parte del repositorio en un nuevo directorio llamado project. Puede editar los ficheros en su copia de trabajo y después depositar esos cambios de nuevo en el repositorio.

Para un recorrido completo por todas las operaciones que puede realizar con su copia de trabajo, vea Capítulo 3, Recorrido guiado.

Llegado este punto, usted tiene la opción de hacer que su repositorio Subversion esté disponible a otros a través de una red. Vea Capítulo 6, Configuración del servidor para aprender acerca de los diferentes tipos de procesos servidor disponibles y cómo configurarlos.

Subversion es un sistema centralizado para compartir información. La parte principal de Subversion es el repositorio, el cual es un almacén central de datos. El repositorio guarda información en forma de árbol de archivos—una típica jerarquía de archivos y directorios. Cualquier número de clientes puede conectarse al repositorio y luego leer o escribir en esos archivos. Al escribir datos, un cliente pone a disposición de otros la información; al leer datos, el cliente recibe información de otros. La figura Figura 2.1, “Un sistema cliente/servidor típico” ilustra ésto.

Figura 2.1. Un sistema cliente/servidor típico

Entonces, ¿qué tiene ésto de interesante?. Hasta ahora, suena como la definición del típico servidor de archivos. Y, de hecho, el repositorio es una especie de servidor de archivos, pero no del tipo habitual. Lo que hace especial al repositorio de Subversion es que recuerda todos los cambios hechos sobre él: cada cambio a cada archivo, e inclusive cambios al propio árbol de directorios, tales como la adición, borrado y reubicación de archivos y directorios.

Cuando un cliente lee datos del repositorio, normalmente sólo ve la ultima versión del árbol de archivos. Sin embargo, el cliente también tiene la posibilidad de ver estados previos del sistema de archivos. Por ejemplo, un cliente puede hacer consultas históricas como, “¿Qué contenía este directorio el miércoles pasado?” Esta es la clase de preguntas que resulta esencial en cualquier sistema de control de versiones: sistemas que están diseñados para registrar y seguir los cambios en los datos a través del tiempo.

La misión principal de un sistema de control de versiones es permitir la edición colaborativa y la compartición de los datos. Sin embargo, existen diferentes sistemas que utilizan diferentes estrategias para alcanzar este objetivo.

El problema de compartir archivos

Todos los sistemas de control de versiones tienen que resolver un problema fundamental: ¿Cómo permitirá el sistema a los usuarios el compartir información, pero al mismo tiempo impedirá que se pisen los callos mutuamente de forma accidental? Es muy sencillo para los usuarios el sobreescribir accidentalmente los cambios de los demás en el repositorio.

Considere el escenario mostrado en Figura 2.2, “El problema a evitar”. Suponga que tenemos dos colaboradores, Juan y Carmen. Cada uno de ellos decide editar el mismo archivo del repositorio al mismo tiempo. Si Juan guarda sus cambios en el repositorio en primer lugar, es posible que (unos momentos más tarde) Carmen los sobreescriba accidentalmente con su propia versión del archivo. Si bien es cierto que la versión de Juan no se ha perdido para siempre (porque el sistema recuerda cada cambio), cualquier cambio que Juan haya hecho no estará presente en la versión más reciente de Carmen porque, para empezar, ella nunca vio los cambios de Juan. El trabajo de Juan sigue efectivamente perdido—o al menos ausente en la última versión del archivo—y probablemente por accidente. ¡Esta es definitivamente una situación que queremos evitar!

Figura 2.2. El problema a evitar

La solución bloqueo-modificación-desbloqueo

Muchos sistemas de control de versiones utilizan un modelo de bloqueo-modificación-desbloqueo para atacar este problema. En un sistema como éste, el repositorio sólo permite a una persona modificar un archivo al mismo tiempo. Juan debe “bloquear” primero el archivo para luego empezar a hacerle cambios. Bloquear un archivo se parece mucho a pedir prestado un libro de la biblioteca; si Juan ha bloqueado el archivo, entonces Carmen no puede hacerle cambios. Por consiguiente, si ella intenta bloquear el archivo, el repositorio rechazará la petición. Todo lo que puede hacer es leer el archivo y esperar a que Juan termine sus cambios y deshaga el bloqueo. Tras desbloquear Juan el archivo, Carmen puede aprovechar su turno bloqueando y editando el archivo. La figura Figura 2.3, “La solución bloqueo-modificación-desbloqueo” demuestra esta sencilla solución.

Figura 2.3. La solución bloqueo-modificación-desbloqueo

El problema con el modelo bloqueo-modificación-desbloqueo es que es un tanto restrictivo y a menudo se convierte en un obstáculo para los usuarios:

• Bloquear puede causar problemas administrativos. En ocasiones Juan bloqueará un archivo y se olvidará de él. Mientras tanto, como Carmen está aún esperando para editar el archivo, sus manos están atadas. Y luego Juan se va de vacaciones. Ahora Carmen debe conseguir que un administrador deshaga el bloqueo de Juan. La situación termina causando muchas demoras innecesarias y pérdida de tiempo.

• Bloquear puede causar una serialización innecesaria. ¿Qué sucede si Juan está editando el inicio de un archivo de texto y Carmen simplemente quiere editar el final del mismo archivo? Estos cambios no se solapan en absoluto. Ambos podrían editar el archivo simultáneamente sin grandes perjuicios, suponiendo que los cambios se combinaran correctamente. No hay necesidad de turnarse en esta situación.

• Bloquear puede causar una falsa sensación de seguridad. Imaginemos que Juan bloquea y edita el archivo A, mientras que Carmen bloquea y edita el archivo B al mismo tiempo. Pero suponga que A y B dependen uno del otro y que los cambios hechos a cada uno de ellos son semánticamente incompatibles. Súbitamente A y B ya no funcionan juntos. El sistema de bloqueo se mostró ineficaz a la hora de evitar el problema—sin embargo, y de algún modo, ofreció una falsa sensación de seguridad. Es fácil para Juan y Carmen imaginar que al bloquear archivos, cada uno está empezando una tarea segura y aislada, lo cual les inhibe de discutir sus cambios incompatibles desde un principio.

La solución copiar-modificar-mezclar

Subversion, CVS y otros sistemas de control de versiones utilizan un modelo del tipo copiar-modificar-mezclar como alternativa al bloqueo. En este modelo, el cliente de cada usuario se conecta al repositorio del proyecto y crea una copia de trabajo personal—una réplica local de los archivos y directorios del repositorio. Los usuarios pueden entonces trabajar en paralelo, modificando sus copias privadas. Finalmente, todas las copias privadas se combinan (o mezclan) en una nueva versión final. El sistema de control de versiones a menudo ayuda con la mezcla, pero en última instancia es un ser humano el responsable de hacer que ésto suceda correctamente.

He aquí un ejemplo. Digamos que Juan y Carmen crean sendas copias de trabajo del mismo proyecto, extraídas del repositorio. Ambos trabajan concurrentemente y hacen cambios a un mismo archivo A dentro de sus copias. Carmen guarda sus cambios en el repositorio primero. Cuando Juan intenta guardar sus cambios más tarde, el repositorio le informa de que su archivo A está desactualizado. En otras palabras, que el archivo A en el repositorio ha sufrido algún cambio desde que lo copió por última vez. Por tanto, Juan le pide a su cliente que mezcle cualquier cambio nuevo del repositorio con su copia de trabajo del archivo A. Es probable que los cambios de Carmen no se solapen con los suyos; así que una vez que tiene ambos juegos de cambios integrados, Juan guarda su copia de trabajo de nuevo en el repositorio. Las figuras Figura 2.4, “La solución copiar-modificar-mezclar” y Figura 2.5, “La solución copiar-modificar-mezclar (continuación)” muestran este proceso.

Figura 2.4. La solución copiar-modificar-mezclar

Figura 2.5. La solución copiar-modificar-mezclar (continuación)

¿Pero qué ocurre si los cambios de Carmen sí se solapan con los de Juan? ¿Entonces qué? Esta situación se conoce como conflicto y no suele suponer un gran problema. Cuando Juan le pide a su cliente que mezcle los últimos cambios del repositorio en su copia de trabajo, su copia del archivo A se marca de algún modo para indicar que está en estado de conflicto: Juan podrá ver ambos conjuntos de cambios conflictivos y escoger manualmente entre ellos. Observe que el programa no puede resolver automáticamente los conflictos; sólo los humanos son capaces de entender y tomar las decisiones inteligentes oportunas. Una vez que Juan ha resuelto manualmente los cambios solapados—posiblemente después de discutirlos con Carmen—ya podrá guardar con seguridad el archivo mezclado en el repositorio.

La solución copiar-modificar-mezclar puede sonar un tanto caótica, pero en la práctica funciona extremadamente bien. Los usuarios pueden trabajar en paralelo, sin tener que esperarse el uno al otro. Cuando trabajan en los mismos archivos, sucede que la mayoría de sus cambios concurrentes no se solapan en absoluto; los conflictos son poco frecuentes. El tiempo que toma resolver los conflictos es mucho menor que el tiempo perdido por un sistema de bloqueos.

Al final, todo desemboca en un factor crítico: la comunicación entre los usuarios. Cuando los usuarios se comunican pobremente, los conflictos tanto sintácticos como semánticos aumentan. Ningún sistema puede forzar a los usuarios a comunicarse perfectamente, y ningún sistema puede detectar conflictos semánticos. Por consiguiente, no tiene sentido dejarse adormecer por la falsa promesa de que un sistema de bloqueos evitará de algún modo los conflictos; en la práctica, el bloqueo parece inhibir la productividad más que otra cosa.

Es hora de movernos de lo abstracto a lo concreto. En esta sección mostraremos ejemplos reales de Subversion en la práctica.

Copias de trabajo

Ya ha leído acerca de las copias de trabajo; ahora demostraremos cómo las crea y las usa el cliente de Subversion.

Una copia de trabajo de Subversion es un árbol de directorios corriente de su sistema de archivos local, conteniendo una colección de archivos. Usted puede editar estos archivos del modo que prefiera y si se trata de archivos de código fuente, podrá compilar su programa a partir de ellos de la manera habitual. Su copia de trabajo es su área de trabajo privada: Subversion nunca incorporará los cambios de otra gente o pondrá a disposición de otros sus cambios hasta que usted le indique explícitamente que lo haga.

Tras hacer algunos cambios a los archivos en su copia de trabajo y verificar que funcionan correctamente, Subversion le proporciona comandos para “publicar” sus cambios al resto de personas que trabajan con usted en su proyecto (escribiendo en el repositorio). Si las demás personas publican sus propios cambios, Subversion le proporciona comandos para mezclar estos cambios en su directorio de trabajo (leyendo del repositorio).

Una copia de trabajo también contiene algunos archivos extra, creados y mantenidos por Subversion para ayudarle a ejecutar estos comandos. En particular, cada directorio de su copia de trabajo contiene un subdirectorio llamado .svn, también conocido como el directorio administrativo de la copia de trabajo. Los archivos en cada directorio administrativo ayudan a Subversion a reconocer qué archivos contienen cambios no publicados y qué archivos están desactualizados con respecto al trabajo hecho por los demás.

Un repositorio típico de Subversion contiene a menudo los archivos (o el código fuente) de varios proyectos; normalmente, cada proyecto es un subdirectorio en el árbol del sistema de archivos del repositorio. En esta disposición, la copia de trabajo de un usuario se corresponde habitualmente con un subárbol particular del repositorio.

Por ejemplo, suponga que usted tiene un repositorio que contiene dos proyectos de software, paint y calc. Cada proyecto reside en su propio subdirectorio dentro del directorio raíz, tal como se muestra en Figura 2.6, “El sistema de archivos del repositorio”.

Figura 2.6. El sistema de archivos del repositorio

Para conseguir una copia de trabajo, debe ejecutar primero un check out de algún subárbol del repositorio. (El término inglés “check out” puede sonar como si tuviera algo que ver con bloquear o reservar recursos, pero no es así; tan sólo crea una copia privada del proyecto para usted). Por ejemplo, si usted hace un check out de /calc, obtendrá una copia de trabajo como ésta:

$ svn checkout http://svn.example.com/repos/calc
A  calc
A  calc/Makefile
A  calc/integer.c
A  calc/button.c

$ ls -A calc
Makefile  integer.c  button.c  .svn/

La lista de letras A indica que Subversion está añadiendo una serie de elementos a su copia de trabajo. Usted ahora tiene una copia personal del directorio /calc del repositorio, con una entrada adicional—.svn—que contiene la información extra que Subversion necesita, tal y como se mencionó anteriormente.

URLs del repositorio

A los repositorios de Subversion se puede acceder a través de diferentes métodos—en el disco local, o a través de varios protocolos de red. Sin embargo, la ubicación de un repositorio es siempre un URL. La tabla 2-1 describe la correspondencia entre los diferentes esquemas de URL y los métodos de acceso disponibles.

Tabla 2.1. URLs de Acceso al Repositorio

Esquema	Método de acceso
file:///	acceso directo al repositorio (en disco local)
http://	acceso vía protocolo WebDAV a un servidor Apache que entiende de Subversion
https://	igual que http://, pero con cifrado SSL.
svn://	acceso vía un protocolo personalizado a un servidor svnserve.
svn+ssh://	igual que svn://, pero a través de un túnel SSH.

En general, los URLs de Subversion utilizan la sintaxis estándar, permitiendo la especificación de nombres de servidores y números de puertos como parte del URL. Recuerde que el método de acceso file: es válido sólo para ubicaciones en el mismo servidor donde se ejecuta el cliente—de hecho, se requiere por convención que la parte del URL con el nombre del servidor esté ausente o sea localhost:

$ svn checkout file:///ruta/a/repositorio
…
$ svn checkout file://localhost/ruta/a/repositorio
…

Además, los usuarios del esquema file: en plataformas Windows necesitarán usar una sintaxis “estándar” extraoficial para acceder a repositorios que están en la misma máquina, pero en una unidad de disco distinta de la que el cliente esté utilizando en el momento. Cualquiera de las dos siguientes sintaxis para rutas de URL funcionarán siendo X la unidad donde reside el repositorio:

C:\> svn checkout file:///X:/ruta/a/repositorio
…
C:\> svn checkout "file:///X|/ruta/a/repositorio"
…

En la segunda sintaxis, es necesario encerrar el URL entre comillas para que la barra vertical no sea interpretada como una tubería.

Nótese que un URL usa barras de separación ordinarias aún cuando la forma de ruta nativa (no para URLs) en Windows utiliza barras invertidas.

Suponga que hace cambios a button.c. Puesto que el directorio .svn recuerda la fecha de modificación del archivo y su contenido original, Subversion es capaz de darse cuenta de que el archivo ha cambiado. Sin embargo, Subversion no hará públicos sus cambios hasta que usted no le diga explícitamente que lo haga. El acto de publicar sus cambios es conocido comúnmente como consignar (o registrar) los cambios al repositorio.

Para publicar sus cambios a otros, usted puede utilizar el comando commit de Subversion:

$ svn commit button.c
Sending        button.c
Transmitting file data .
Committed revision 57.

Ahora sus cambios a button.c han sido consignados al repositorio; si otro usuario obtiene una copia de trabajo de /calc, podrá ver sus cambios en la última versión del archivo.

Suponga que tiene un colaborador, Carmen, quien obtuvo una copia de trabajo de /calc al mismo tiempo que usted. Cuando usted envía sus cambios sobre button.c, la copia de trabajo de Carmen se deja sin cambios; Subversion solo modifica las copias de trabajo a petición del usuario.

Para tener su proyecto actualizado, Carmen puede pedir a Subversion que proceda a actualizar su copia de trabajo, usando para ello el comando update de Subversion. Ésto incorporará los cambios hechos por usted en la copia de trabajo de Carmen, así como otros cambios consignados desde que ella hizo el check out.

$ pwd
/home/sally/calc

$ ls -A 
.svn/ Makefile integer.c button.c

$ svn update
U button.c

La salida del comando svn update indica que Subversion actualizó el contenido de button.c. Observe que Carmen no necesitó especificar qué archivos actualizar; Subversion usa la información del directorio .svn, junto con información adicional del repositorio, para decidir qué archivos necesitan una actualización.

Revisiones

Una operación svn commit puede publicar los cambios sobre cualquier número de ficheros y directorios como una única transacción atómica. En su copia privada, usted puede cambiar el contenido de los ficheros, crear, borrar, renombrar y copiar ficheros y directorios, y luego enviar el conjunto entero de cambios como si se tratara de una unidad.

En el repositorio, cada cambio es tratado como una transacción atómica: o bien se realizan todos los cambios, o no se realiza ninguno. Subversion trata de conservar esta atomicidad para hacer frente a posibles fallos del programa, fallos del sistema, problemas con la red, y otras acciones del usuario.

Cada vez que el repositorio acepta un envío, éste da lugar a un nuevo estado del árbol de ficheros llamado revisión. A cada revisión se le asigna un número natural único, una unidad mayor que el número de la revisión anterior. La revisión inicial de un repositorio recién creado se numera con el cero, y consiste únicamente en un directorio raíz vacío.

La Figura 2.7, “El repositorio” ilustra una manera interesante de ver el repositorio. Imagine un array de números de revisión, comenzando por el 0, que se extiende de izquierda a derecha. Cada número de revisión tiene un árbol de ficheros colgando debajo de él, y cada árbol es una “instantánea” del aspecto del repositorio tras cada envío.

Figura 2.7. El repositorio

Números de revisión global

A diferencia de muchos otros sistemas de control de versiones, los números de revisión de Subversion se aplican a árboles enteros, no a ficheros individuales. Cada número de revisión selecciona un árbol completo, un estado particular del repositorio tras algún cambio publicado. Otra manera de ver ésto es que la revisión N representa el estado del sistema de ficheros del repositorio tras el envío de cambios N-ésimo. Cuando un usuario de Subversion habla de la “revisión 5 de foo.c”, lo que realmente quiere decir es “foo.c tal como aparece en la revisión 5.” Observe que en general, ¡las revisiones N y M de un fichero no tienen por qué ser diferentes necesariamente! Dado que CVS utiliza números de revisión para cada fichero, los usuarios de CVS pueden querer echar un vistazo a Apéndice A, Subversion para usuarios de CVS para más detalles.

Es importante observar que las copias de trabajo no siempre se corresponden con una revisión en particular del repositorio; pueden contener ficheros de varias revisiones diferentes. Por ejemplo, suponga que obtiene una copia de trabajo de un repositorio cuya revisión más reciente es la 4:

calc/Makefile:4
     integer.c:4
     button.c:4

Por el momento, esta copia de trabajo se corresponde exactamente con la revisión 4 del repositorio. Sin embargo, suponga que realiza un cambio a button.c y lo publica. Suponiendo que no se han realizado otros envíos, el suyo creará la revisión 5 del repositorio, y su copia de trabajo aparecerá ahora así:

calc/Makefile:4
     integer.c:4
     button.c:5

Suponga que, en este punto, Carmen envía un cambio a integer.c, creando la revisión 6. Si usted usa svn update para actualizar su copia de trabajo, ésta se verá ahora como:

calc/Makefile:6
     integer.c:6
     button.c:6

Los cambios de Carmen sobre