Hablando conceptualmente, un repositorio Subversion es una secuencia de árboles de directorios. Cada árbol es una fotografía de cómo eran los ficheros y directorios versionados en tu repositorio en un momento determinado. Estas fotografías son generadas como resultado de operaciones de programas cliente, y son llamadas revisiones.

Cada revisión nace como un árbol de transacciones. Cuando se envían cambios al repositorio, el programa cliente construye una transacción de Subversion que copia los cambios locales ( junto a cualquier cambio adicional que haya podido tener lugar desde el comienzo del proceso de envío de datos), y luego pide al repositorio que guarde ese árbol como la próxima fotografía en la secuencia. Si el envío de datos no da error, la transacción se convierte en una nueva revisión del árbol, y se le asigna un nuevo número de revisión. Si el envío de datos fallara por alguna razón, la transacción se destruye, y se le informa al cliente del error.

Las actualizaciones funcionan de una manera parecida. El Cliente prepara un árbol de transacción temporal que copia el estado de la copia de trabajo. El repositorio compara entonces ese árbol de transacción con el árbol de la revisión solicitada (normalmente la más reciente, o el árbol “más joven”), e informa al cliente acerca de qué cambios son necesario para convertir su copia local de trabajo en una réplica de ese árbol de revisión. Tras completarse la actualización, se borra la transacción temporal.

El uso de árboles de transacción es la única manera de hacer cambio permanentes en un repositorio de sistema de ficheros versionados. De todas maneras, es importante entender que el tiempo de vida de una transacción es completamente flexible. En el caso de actualizaciones, las transacciones con árboles temporales que se destruyen inmediatamente. En el caso de envíos al repositorio, las transacciones son transformadas en revisiones permanentes ( o borradas si el envío falla ). En el caso de un error, es posible que una transacción permanezca accidentalmente suelta en el repositorio ( sin que afecte en realidad a nada, pero ocupando espacio).

En teoría, un día los programas de flujo de trabajo completo deberán girar hacia un control más fino del tiempo de vida de la transacción. Es factible imaginar un sistema por el que cada transacción que se convierta en revisión permanezca en bastante después de que el cliente termine de describir sus cambios al repositorio. Esto permitiría que cada nuevo envío sea revisado por alguna otra persona, quizás un director o , que pueda elegir entre promoverla a una revisión, o cancelarla.

Las transacciones y las revisiones en el repositorio Subversion pueden tener propiedades adjuntas. Estas propiedades son relaciones genéricas clave-valor, y generalmente se usan para guardar información acerca del árbol al que están adjuntas. Los nombres y valores de estas propiedades se guardan en el sistema de ficheros del repositorio, junto con el resto de los datos de tu árbol.

Las propiedades de revisiones y transacciones son útiles para asociar información con un árbol que no está estrictamente relacionada con los ficheros y directorios de ese árbol—el tipo de información que no es gestiona por las copias de trabajo de cliente. Por ejemplo, cuando una nueva transacción de envío es creada en el repositorio, Subversion añade una propiedad a dicha transacción llamada svn:date— una marca de tiempo que representa el momento en que la transacción se creó. En el momento que el proceso de envío termina, el árbol también ha recibido una propiedad para guardar el nombre del usuario que es autor de la revisión (svn:author) y una propiedad para guardar el mensaje de informe de cambios adjunto a dicha revisión (svn:log).

Las propiedades de revisiones y transacciones son propiedades no versionada—cuando son modificadas, sus valores previos se descartan definitivamente. Así mismo, mientras los árboles de revisiones en sí son inmutables, las propiedades adjuntas de dichos árboles no lo son. Puedes añadir, borrar, y modificar propiedades de revisiones en cualquier momento más adelante. Si envías al repositorio una nueva revisión y más tarde te das cuenta de alguna información incorrecta o un error sintáctico en tu mensaje de log, puedes simplemente sustituir el valor de la propiedad svn:log con un nuevo y corregido mensaje de log.

Los datos almacenados dentro de repositorios Subversion, realmente se encuentran en una base de datos, más concretamente, un fichero de base de datos Berkeley. Durante la fase inicial de diseño de Subversion, los desarrolladores decidieron usar una base de datos Berkeley por una serie de razones, como su licencia open-source, soporte de transacciones, ser de confianza, funcionamiento, simplicidad de su API, soporte de hilos, cursores, y más.

La base de datos Berkeley tiene un soporte real de transacciones —probablemente es su característica más poderosa. Muchos procesos que acceden a sus repositorios Subversion no tienen que preocuparse por pisotear los datos de otros. El aislamiento provisto por el sistema de transacciones es tal que por cada operación dada, el código de repositorio Subversion tiene una vista estática de la base de datos—no una base de datos que está constantemente cambiando de la mano de algunos otros procesos—y puede tomar decisiones basándose en esa vista. Si dicha decisión está en conflicto con lo que otro proceso esté haciendo, la operación completa como si nunca hubiera sucedido, y Subversion reintenta la operación contra una nueva y actualizada ( y estática ) vista de la base de datos.

Otra gran característica de la base de datos Berkeley son las copias de seguridad en caliente— la habilidad para hacer una copia de seguridad del entorno de la base de datos sin que tenga que estar “”. Hablaremos sobre cómo hacer copias de seguridad de tu repositorio en “Copias de seguridad del repositorio”, pero los beneficios de ser capaz de hacer copias completas y funcionales de tus repositorios sin debería ser obvia.

La base de datos Berkeley también es un sistema de bases de datos de mucha confianza. Subversion utiliza las utilidades de registro de las bases de datos Berkeley, lo que significa que la base datos primero escribe una descripción de cualquier modificación que vaya a hacer en ficheros de registros, para luego hace la propia modificación. Esto es para asegurar que si algo fuese mal, el sistema de base de datos pueda retroceder a un checkpoint—una posición en los ficheros de registro que se sabe que no están corruptas—y repetir transacciones hasta que los datos estén en un estado usable. Ver “Gestionando el espacio de almacenamiento” si quieres más información acerca de los ficheros de registro de las bases de datos de Berkeley.

Pero toda rosa tiene su espina, así que tenemos que hablar sobre algunas conocidas limitaciones de la base de datos Berkeley. Primero, los entornos de base de datos Berkeley no son portables. No puedes copiar simplemente un repositorio Subversion que fue creado en un sistema Unix a un sistema Windows y esperar que funcione. A pesar de que la mayor parte del formato de base de datos Berkeley es independiente de la arquitectura, hay otros aspectos del entorno que no lo son. Segundo, Subversion usa la base de datos Berkeley de una manera que no puede funcionar en sistemas Windows 95/98—si necesita almacenar un repositorio en una máquina Windows, utilice Windows 2000 o Windows XP. Finalmente, no deberías mantener un repositorio Subversion en una unidad compartida por red. Mientras las bases de datos Berkeley prometen un comportamiento correcto en unidades compartidas por red que cumplan un grupo particular de especificaciones, casi ningún sistema de compartición conocido cumple con todas esas especificaciones.