Subversion tiene un diseño modular, implementado como un grupo de librerías en C. Cada librería tiene un propósito e interfaz bien definidos, y la mayoría de los módulos se puede decir que existen en una de tres posibles capas—capa de repositorio, capa de acceso al repositorio (RA[42]), o capa de cliente. Examinaremos en breve estas capas, pero antes, vea un corto inventario de las librerías de Subversion en Tabla 8.1, “Un corto inventario de las librerías de Subversion”. En aras de la consistencia, nos referiremos a estas librerías por sus nombres de librería Unix sin extensión (por ejemplo: libsvn_fs, libsvn_wc, mod_dav_svn).
Tabla 8.1. Un corto inventario de las librerías de Subversion
| Librería | Descripción |
|---|---|
| libsvn_client | Interfaz principal para programas cliente |
| libsvn_delta | Rutinas de diferenciado de árboles y texto |
| libsvn_fs | Librería del sistema de ficheros de Subversion |
| libsvn_ra | Utilidades comunes de acceso al repositorio y módulo cargador |
| libsvn_ra_dav | Módulo de acceso WebDav al repositorio |
| libsvn_ra_local | Módulo de acceso local al repositorio |
| libsvn_ra_svn | Módulo de acceso al repositorio mediante protocolo personalizable |
| libsvn_repos | Interfaz del repositorio |
| libsvn_subr | Miscelánea de subrutinas útiles |
| libsvn_wc | Librería para la gestión de la copia local de trabajo |
| mod_authz_svn | Módulo de autorización de Apache para acceso a repositorios Subversion vía WebDAV |
| mod_dav_svn | Módulo Apache para relacionar operaciones WebDAV con operaciones Subversion |
El hecho de que la palabra “miscelánea” sólo aparezca una vez en Tabla 8.1, “Un corto inventario de las librerías de Subversion” es una buena señal. El equipo de desarrollo de Subversion está seriamente dedicado a que las funcionalidades vivan en la capa y librería correctas. Quizás la mayor de las ventajas del diseño modular es su falta de complejidad desde el punto de vista de un desarrollador. Como desarrollador, usted puede formular rápidamente este “gran mapa” que le permite marcar la ubicación de ciertas partes de la funcionalidad con relativa facilidad.
Otro gran beneficio de la modularidad es la posibilidad de reemplazar un módulo concreto con una nueva librería que implementa la misma API sin afectar al resto del código fuente. En cierto sentido, esto ya ocurre dentro de Subversion. Las librerías libsvn_ra_dav, libsvn_ra_local, y libsvn_ra_svn implementan la misma interfaz. Y las tres se comunican con la capa de repositorio;libsvn_ra_dav y libsvn_ra_svn lo hacen a través de la red, mientras que libsvn_ra_local accede directamente.
El propio cliente es una muestra de la modularidad del diseño de Subversion. A pesar de que Subversion por ahora sólo viene con un programa cliente de línea de comando, ya hay en desarrollo unos cuantos programas por parte de terceros que actúan como interfaces gráficas de Subversion. De nuevo, estos GUIs usan las mismas APIs que el cliente de línea de comando que viene de serie. La librería de Subversion libsvn_client es como una tienda de paso con la mayor parte de la funcionalidad necesaria para diseñar un cliente de Subversion (vea “Capa cliente”).
Cuando nos referimos a la capa de repositorio de Subversion, en general estamos hablando de dos librerías—la librería de repositorio, y la librería del sistema de ficheros. Estas librerías proporcionan los mecanismos de almacenamiento e informe para las varias revisiones de sus datos bajo control de versiones. Esta capa está conectada a la capa cliente vía capa de acceso al repositorio, y son, desde el punto de vista del usuario de Subversion, las cosas “al otro lado de la línea.”
Al sistema de ficheros de Subversion se accede vía la API de libsvn_fs, y no se trata de un sistema de ficheros que uno instalaría en un sistema operativo (como ext2 de Linux o NTFS), sino un sistema de ficheros virtual. En lugar de almacenar “ficheros” y “directorios” como ficheros y directorios reales (vamos, el tipo que puede explorar usando su programa favorito de shell), usa un sistema de base de datos para sus mecanismos back-end de almacenamiento. Actualmente el sistema de base de datos que usa es la base de datos de Berkeley. [43] No obstante, en la comunidad de desarrolladores ha habido un considerable interés para que futuras versiones de Subversion tengan la capacidad para usar otros sistemas back-ends de base de datos, quizás a través de mecanismos como la Open Database Connectivity (ODBC).
La API de sistema de ficheros exportada por libsvn_fs contiene el tipo de funcionalidad que esperaría de cualquier otro API de sistema de ficheros: puede crear y borrar ficheros y directorios, copiarlos y moverlos, modificar el contenido de ficheros, y un largo etcétera. También tiene características que no son tan comunes, como la habilidad de añadir, modificar o eliminar meta datos (“propiedades”) sobre cualquier fichero o directorio. Además, el sistema de ficheros de Subversion es versionado, lo que significa que a medida que realiza cambios a su árbol de directorios, Subversion recuerda el aspecto que tenía el árbol antes de esos cambios. Y antes que los cambios anteriores. Y que los anteriores a los anteriores. Y así todo el camino de vuelta por el tiempo de versionado hasta el momento inicial en el cual comenzó a añadir cosas al sistema de ficheros.
Todas las modificaciones que haga a su árbol se realizarán en el contexto de una transacción de Subversion. Lo siguiente es una rutina general simplificada para modificar su sistema de ficheros:
-
Comience una transacción de Subversion.
-
Realice sus cambios (adiciones, borrados, modificación de propiedades, etc.).
-
Finalice su transacción.
Una vez ha finalizado su transacción, las modificaciones a su sistema de ficheros se almacenan permanentemente como artefactos históricos . Cada uno de estos ciclos genera una nueva revisión de su árbol, y cada revisión es accesible para siempre como una instantánea inmutable de “cómo estaban las cosas.”
La mayoría de la funcionalidad proporcionada por la
interfaz del sistema de ficheros se muestra como acciones
que trabajan sobre una ruta del sistema de ficheros.
Es decir, desde un punto de vista externo, el mecanismo
principal para describir y acceder a las revisiones
individuales de ficheros y directorios son las cadenas
con rutas como /foo/bar, igual que si
estuviese tratando con ficheros y directorios a través de
su programa favorito de línea de comando. Añada nuevos
ficheros y directorios pasando sus futuras rutas a las
funciones correctas de la API. Obtenga información sobre
ellos usando el mismo mecanismo.
No obstante, a diferencia de la mayoría de los sistemas de ficheros, una ruta sola no es información suficiente para identificar un fichero o directorio en Subversion. Piense que el árbol de directorios es un sistema bidimensional, donde los nodos hermanos representan una especie de movimiento izquierda-derecha, y descender en subdirectorios un movimiento hacia abajo. Figura 8.1, “Ficheros y directorios en dos dimensiones” muestra una representación típica de un árbol justo de ese modo.
Por supuesto, el sistema de ficheros de Subversion
tiene una genial tercera dimensión que muchos sistemas de
ficheros no tienen—¡El tiempo!
[44]
En la interfaz del sistema de ficheros, casi toda función
que tiene un parámetro de ruta
espera también un parámetro raíz.
Este parámetro svn_fs_root_t
describe una revisión o una transacción de Subversion (la
cual es normalmente una futura revisión), y proporciona
ese contexto tridimensional necesario para entender la
diferencia entre /foo/bar de la revisión
32, y la misma ruta tal y como existe en la revisión 98.
Figura 8.2, “Versionando el tiempo—¡la tercera dimensión!” muestra la historia de
versiones como una dimensión añadida al universo del sistema
de ficheros de Subversion.
Tal y como mencionamos anteriormente, la API de libsvn_fs tiene el aspecto de cualquier otro sistema de ficheros, excepto por el hecho de tener la maravillosa capacidad de versionado. Fue diseñada para ser usada por cualquier programa interesado en un sistema de ficheros versionado. A su vez, Subversion está interesado en esa funcionalidad. Pero mientras que la API del sistema de ficheros debería ser suficiente para tener soporte básico de versionado de ficheros y directorios, Subversion quiere más—y es ahí donde entra en juego libsvn_repos.
La librería de repositorio de Subversion (libsvn_repos) es básicamente una librería envoltorio sobre la funcionalidad del sistema de ficheros. Esta librería es responsable de crear la estructura del repositorio, asegurarse de que el sistema de ficheros subyacente está inicializado, etc. Libsvn_repos también implementa un conjunto de ganchos—scripts que son ejecutados por el código de repositorio cuando se realizan ciertas tareas. Estos scripts son útiles para notificar, autorizar, o cualquier cosa deseada por el administrador del repositorio. Este tipo de funcionalidad, y otras utilidades proporcionadas por la librería de repositorio, no están estrictamente relacionadas con la implementación de un sistema de ficheros versionados, razón por la cual fue colocada en su propia librería.
Los desarrolladores que deseen usar la API de libsvn_repos se encontrarán con que no es un envoltorio completo sobre la interfaz del sistema de ficheros. Es decir, sólo ciertos eventos de categoría en el ciclo general de la actividad del sistema de ficheros están envueltos por la interfaz de repositorio. Algunos de éstos incluyen la creación y enviado de transacciones Subversion, y la modificación de propiedades de revisiones. Estos eventos particulares están envueltos por la capa de repositorio porque tienen enganches asociados con ellos. En el futuro, puede que otros eventos sean envueltos por la API de repositorio. Mientras tanto, el resto de la interacción con el sistema de ficheros continuará ocurriendo directamente vía la API de libsvn_fs.
Por ejemplo, aquí tiene un segmento de código que
ilustra el uso de ambas interfaces (repositorio y sistema
de ficheros) para crear una nueva revisión del sistema de
ficheros en la cual se añade un directorio. Tenga en cuenta
que en este ejemplo (y todos los demás del libro), la macro
SVN_ERR simplemente verifica de forma
booleana el código de retorno de la función que envuelve,
y retorna si hay algún error.
Ejemplo 8.1. Usando la capa de repositorio
/* Create a new directory at the path NEW_DIRECTORY in the Subversion
repository located at REPOS_PATH. Perform all memory allocation in
POOL. This function will create a new revision for the addition of
NEW_DIRECTORY. */
static svn_error_t *
make_new_directory (const char *repos_path,
const char *new_directory,
apr_pool_t *pool)
{
svn_error_t *err;
svn_repos_t *repos;
svn_fs_t *fs;
svn_revnum_t youngest_rev;
svn_fs_txn_t *txn;
svn_fs_root_t *txn_root;
const char *conflict_str;
/* Open the repository located at REPOS_PATH. */
SVN_ERR (svn_repos_open (&repos, repos_path, pool));
/* Get a pointer to the filesystem object that is stored in
REPOS. */
fs = svn_repos_fs (repos);
/* Ask the filesystem to tell us the youngest revision that
currently exists. */
SVN_ERR (svn_fs_youngest_rev (&youngest_rev, fs, pool));
/* Begin a new transaction that is based on YOUNGEST_REV. We are
less likely to have our later commit rejected as conflicting if we
always try to make our changes against a copy of the latest snapshot
of the filesystem tree. */
SVN_ERR (svn_fs_begin_txn (&txn, fs, youngest_rev, pool));
/* Now that we have started a new Subversion transaction, get a root
object that represents that transaction. */
SVN_ERR (svn_fs_txn_root (&txn_root, txn, pool));
/* Create our new directory under the transaction root, at the path
NEW_DIRECTORY. */
SVN_ERR (svn_fs_make_dir (txn_root, new_directory, pool));
/* Commit the transaction, creating a new revision of the filesystem
which includes our added directory path. */
err = svn_repos_fs_commit_txn (&conflict_str, repos,
&youngest_rev, txn, pool);
if (! err)
{
/* No error? Excellent! Print a brief report of our success. */
printf ("Directory '%s' was successfully added as new revision "
"'%" SVN_REVNUM_T_FMT "'.\n", new_directory, youngest_rev);
}
else if (err->apr_err == SVN_ERR_FS_CONFLICT)
{
/* Uh-oh. Our commit failed as the result of a conflict
(someone else seems to have made changes to the same area
of the filesystem that we tried to modify). Print an error
message. */
printf ("A conflict occurred at path '%s' while attempting "
"to add directory '%s' to the repository at '%s'.\n",
conflict_str, new_directory, repos_path);
}
else
{
/* Some other error has occurred. Print an error message. */
printf ("An error occurred while attempting to add directory '%s' "
"to the repository at '%s'.\n",
new_directory, repos_path);
}
/* Return the result of the attempted commit to our caller. */
return err;
}
En el segmento de código anterior, se hacen llamadas
tanto a las interfaces de repositorio como de sistema de
ficheros. Igualmente podríamos haber enviado la transacción
usando svn_fs_commit_txn. Pero la API
del sistema de ficheros no sabe nada sobre los mecanismos
de enganche de la librería del repositorio. Si quiere que
su repositorio de Subversion realice automáticamente un
conjunto de tareas no relacionadas con Subversion cada vez
que envía una transacción (como por ejemplo, enviar un email
que describe los cambios realizados en esa transacción
a su lista de correo de desarrolladores), necesita
usar la versión envoltorio de la función libsvn_repos
apropiada—svn_repos_fs_commit_txn.
Esta función en realidad ejecutará primero el script de
enganche pre-commit si existe, entonces
enviará la transacción, y finalmente ejecutará el script
de enganche post-commit. Los ganchos
proporcionan un mecanismo especial de información que no
pertenece a la librería del núcleo del sistema de ficheros.
(Para más información sobre los ganchos de repositorio de
Subversion, lea “Scripts de enganche”.)
El requisito del mecanismo de enganches es una de las razones para abstraer la librería de repositorio del código del sistema de ficheros. La API libsvn_repos proporciona algunas otras utilidades importantes para Subversion. Entre ellas está la capacidad para:
-
crear, abrir, destruir y realizar los pasos de recuperación sobre un repositorio Subversion y el sistema de ficheros incluido en el mismo.
-
describir las diferencias entre dos árboles de sistema de ficheros.
-
obtener el informe de cambios asociado con todas (o algunas) las revisiones en las cuales un conjunto de ficheros fue modificado en el sistema de ficheros.
-
generar un “volcado” legible por un humano del sistema de ficheros, una representación completa de las revisiones en el sistema de ficheros.
-
procesar el formato de ese volcado, cargando revisiones volcadas en un repositorio Subversion diferente.
A medida que Subversion continúa evolucionando, la librería de repositorio seguirá creciendo con la librería del sistema de ficheros para ofrecer una mayor funcionalidad y soporte configurable de opciones.
Si la capa de repositorio de Subversion está “al otro lado de la línea”, la capa de acceso al repositorio está en la propia línea. Destinada a serializar los datos entre las librerías cliente y el repositorio, esta capa incluye la librería cargadora del módulo libsvn_ra, los propios módulos RA (que por ahora son libsvn_ra_dav, libsvn_ra_local, y libsvn_ra_svn), y cualquier librería adicional necesaria por uno o varios de esos módulos RA, como por ejemplo el módulo mod_dav_svn de Apache que se comunica con libsvn_ra_dav o el servidor de libsvn_ra_svn, svnserve.
Dado que Subversion usa URLs para identificar los
recursos del repositorio, la porción de protocolo del
esquema URL (normalmente file:,
http:, https:, o
svn:) es usada para determinar qué módulo
RA se encargará de las comunicaciones. Cada módulo registra
una lista de los protocolos que sabe “hablar”
por lo que el cargador de RA puede, en tiempo de ejecución,
determinar qué modulo usar para cada tarea concreta. Puede
determinar qué módulos RA están disponibles en el cliente
de línea de comando de Subversion, y qué protocolos dice
soportar, ejecutando svn --version:
$ svn --version svn, version 1.0.1 (r9023) compiled Mar 17 2004, 09:31:13 Copyright (C) 2000-2004 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet (http://www.Collab.Net/). The following repository access (RA) modules are available: * ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol. - handles 'http' schema - handles 'https' schema * ra_local : Module for accessing a repository on local disk. - handles 'file' schema * ra_svn : Module for accessing a repository using the svn network protocol. - handles 'svn' schema
La librería libsvn_ra_dav está diseñada para ser
usada por clientes que están siendo ejecutado en diferentes
máquinas que los servidores con los que se comunican,
específicamente servidores a los que se ha alcanzado
usando URLs que contienen las porciones de protocolo
http: o https:. Para
entender cómo funciona este módulo, deberíamos mencionar
primero un grupo de componentes clave en esta configuración
particular de capa de acceso al repositorio—el
poderoso servidor HTTP Apache, y la librería cliente Neon
HTTP/WebDAV.
El servidor principal de red de Subversion es el servidor HTTP Apache. Apache es un proceso servidor open-source extensible probado por mucho tiempo, preparado para uso serio. Puede soportar una elevada carga de red y se ejecuta en muchas plataformas. El servidor Apache soporta una variedad de protocolos de autenticación estándar, y puede expandirse por medio de módulos para soportar muchos más. También soporta optimizaciones de red como pipelining y caching. Usando Apache como servidor, Subversion obtiene todas estas características gratuitamente. Y dado que la mayoría de los cortafuegos ya permiten que pase el tráfico HTTP, los administradores de sistemas normalmente no tienen que cambiar siquiera la configuración de su cortafuegos para permitir que Subversion funcione.
Subversion usa HTTP y WebDAV (junto con DeltaV) para comunicarse con un servidor Apache. Puede leer más sobre esto en la sección WebDAV de este capítulo, pero en pocas palabras, WebDAV y DeltaV son extensiones al protocolo HTTP 1.1 estándar que permiten compartir y versionar ficheros a través de la web. Apache 2.0 viene con mod_dav, un módulo Apache que entiende las extensiones DAV de HTTP. El propio Subversion proporciona mod_dav_sv, que es otro módulo de Apache que funciona junto con mod_dav (realmente, es su motor) para proporcionar implementaciones específicas de Subversion de WebDAV y DeltaV.
Cuando se comunica con un repositorio por HTTP,
la librería cargadora RA selecciona libsvn_ra_dav como el
módulo correcto de acceso. El cliente de Subversion realiza
llamadas sobre la interfaz genérica RA, y libsvn_ra_dav
relaciona esas llamadas (que tienden a englobar acciones
Subversion a gran escala) con un conjunto de peticiones
HTTP/WebDAV. Usando la librería Neon, libsvn_ra_dav
transmite esas peticiones al servidor Apache. Apache
recibe estas peticiones (exactamente igual que con las
peticiones genéricas HTTP que su navegador pudiera hacer),
se da cuenta de que estas peticiones están dirigidas
a una URL que está configurada como una ubicación
DAV (usando la directiva Location
en httpd.conf), y pasa la petición
a su propio módulo mod_dav. Configurado correctamente,
mod_dav sabe que debe usar mod_dav_svn de Subversion para
cualquier necesidad relacionada con el sistema de ficheros,
a diferencia del módulo genérico mod_dav_fs que viene
con Apache. Así que finalmente el cliente se comunica
con mod_dav_svn, que enlaza directamente con la capa de
repositorio de Subversion.
Pero eso es una descripción simplificada de los intercambios reales que ocurren. Por ejemplo, el repositorio Subversion podría estar protegido por las directivas de autorización de Apache. Esto podría significar que los intentos iniciales de comunicación con el repositorio podrían ser rechazados por Apache debido al código de autorización. En esta situación, libsvn_ra_dav recibe la notificación de Apache de que no se proporcionaron suficientes datos de identificación, y llama de vuelta a la capa cliente para obtener algunos datos actualizados de autenticación. Si los datos se proporcionan correctamente, y el usuario tiene los permisos que Apache necesita, el siguiente intento automático de libsvn_ra_dav para realizar la operación original será aceptado, y todo irá bien. Si no se puede proporcionar suficiente información de autenticación, la petición fallará, y el cliente informará del fallo al usuario.
Gracias al uso de Neon y Apache, Subversion también obtiene funcionalidad gratuita en algunas otras áreas complejas. Por ejemplo, si Neon encuentra las librerías OpenSSL, permitirá al cliente de Subversion intentar usar comunicaciones cifradas con SSL con el servidor Apache (cuyo módulo mod_ssl puede “hablar el lenguaje”). Además, tanto Neon como mod_deflate de Apache pueden entender el algoritmo “deflate” (el mismo usado por los programas PKZIP y gzip), por lo que las peticiones pueden ser enviadas en trozos comprimidos más pequeños a través del cable. Otras características complejas que Subversion espera soportar en el futuro incluyen la capacidad de manejar de forma automática las redirecciones indicadas por el servidor (por ejemplo, cuando un repositorio se mueve a otra nueva URL canónica) y obtener la ventaja del pipelining HTTP.
Además del protocolo estándar HTTP/WebDAV, Subversion
también proporciona una implementación RA que usa un
protocolo propio. El módulo libsvn_ra_svn implementa su
propia conectividad por red, y se comunica con un servidor
autosuficiente—el
programa svnserve—
en la máquina que almacena el repositorio. Los
clientes acceden al repositorio usando el esquema
svn://.
Esta implementación RA carece de la mayoría de las
ventajas de Apache mencionadas en la sección anterior;
no obstante, puede ser atractiva para algunos
administradores de sistemas. Es dramáticamente más
fácil de configurar y ejecutar; configurar un proceso
svnserve es casi instantáneo.
También es mucho más pequeño (en líneas de código) que
Apache, haciéndolo más fácil de auditar, por razones de seguridad u otras. Además,
algunos administradores de sistemas pueden tener ya
instalada una infraestructura de seguridad SSH, que quieren
que Subversion aproveche. Los clientes usando ra_svn pueden
canalizar fácilmente el protocolo por SSH.
No todas las comunicaciones con un repositorio
Subversion requieren un todopoderoso proceso servidor y
una capa de red. Para los usuarios que simplemente desean
acceder a los repositorios de sus discos duros locales,
pueden hacerlo usando URLs file: y la
funcionalidad proporcionada por libsvn_ra_local. Este
módulo RA enlaza directamente con las librerías de
repositorio y sistema de ficheros, por lo que no se
requiere comunicación por red en absoluto.
Subversion requiere que el nombre del servidor
incluido como parte de la URL file:
esté vacío o sea localhost, y
que no exista especificación alguna de puerto. En
otras palabras, las URLs deberían ser como
file://localhost/ruta/al/repositorio
o file:///ruta/al/repositorio.
Además, tenga en cuenta que las URLS
file: de Subversion no pueden ser
usadas en un navegador normal al igual que con la
URL file: típica. Cuando intenta
visualizar una URL file: en un
navegador normal, lee y muestra el contenido del fichero
que está en ese lugar examinando el sistema de ficheros
directamente. No obstante, los recursos de Subversion
existen en un sistema de ficheros virtual (vea “Capa de repositorio”), y su navegador no
será capaz de entender cómo leer este sistema de
ficheros.
Para aquellos que deseen acceder al repositorio Subversion usando todavía otro protocolo, ¡para eso precisamente está modularizada la capa de acceso al repositorio! Los desarrolladores pueden simplemente escribir una nueva librería que implemente la interfaz RA en un lado y se comunique con el repositorio por el otro. Su nueva librería puede usar protocolos de red existentes, o puede inventarse uno propio. Puede usar llamadas de comunicación inter-proceso (IPC), o—tiremos la casa por la ventana, ¿de acuerdo—podría incluso implementar un protocolo basado en email. Subversion proporciona las APIs; usted proporciona la creatividad.
En el lado del cliente, la copia local de trabajo de Subversion es donde ocurre toda la acción. El grueso de la funcionalidad implementada por las librerías en el lado del cliente existe con el único propósito de gestionar copias locales de trabajo—directorios llenos de ficheros y otros subdirectorios que sirven a modo de “reflejo” local y editable de una o más ubicaciones de repositorio—y propagar cambios hacia y desde la capa de acceso al repositorio.
La librería de Subversion de copias locales de trabajo,
libsvn_wc, es directamente responsable de gestionar los
datos en las copias locales. Para realizar esta tarea,
la librería almacena información administrativa sobre cada
directorio dentro de un subdirectorio especial. Este
subdirectorio, llamado .svn,
está presente en cada directorio de la copia local y
contiene varios ficheros y directorios que almacenan el
estado y proporcionan un espacio de trabajo privado para
acciones administrativas. Para aquellos familiarizados
con CVS, este subdirectorio .svn es
similar en propósito a los directorios administrativos
CVS encontrados en las copias de
trabajo locales de CVS. Para más información sobre el
área administrativa .svn, vea “Dentro del área de administración de la copia local de trabajo”en este capítulo.
La librería cliente de Subversion, libsvn_client, tiene
la más amplia responsabilidad; su trabajo es reunir la
funcionalidad de la librería de copia local de trabajo y la
de la capa de acceso al repositorio, y entonces proporcionar
la API de mayor nivel para cualquier aplicación que desee
realizar acciones generales de control de revisiones. Por
ejemplo, la función svn_client_checkout
recibe una URL como parámetro. La función pasa la URL a la
capa RA y abre una sesión autenticada con un repositorio en
particular. Entonces le pregunta al repositorio por un árbol
concreto y envía este árbol a la librería de copia local de
trabajo, la cual escribe entonces una copia local de trabajo
completa en el disco (directorios .svn
y demás incluidos).
La librería cliente está diseñada para que pueda ser usada por cualquier aplicación. Aunque el código fuente de Subversion incluye un cliente estándar de línea de comando, debería ser muy sencillo escribir cualquier número de clientes gráficos sobre esta librería cliente. Nuevas interfaces gráficas (o realmente, cualquier cliente) para Subversion no tienen que ser envoltorios precarios sobre el cliente incluido de línea de comando—tienen acceso completo vía la API de libsvn_client a la misma funcionalidad, datos, y mecanismos de retrollamada usados por el cliente de línea de comando.
[42] N.T.: “repository access”.
[43] La elección de la base de datos de Berkeley trajo varias características de forma automática que Subversion necesitaba, como integridad de datos, escrituras atómicas, recuperabilidad, y copias de seguridad en caliente.
[44] Entendemos que esto pueda ser un jarro de agua fría a todos los fans de la ciencia ficción, quienes durante mucho tiempo han considerado el tiempo como la cuarta dimensión, y pedimos disculpas si provocamos algún trauma emocional con nuestra aserción de una teoría diferente.