Diseño de librería por capas

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”).

Capa de repositorio

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:

  1. Comience una transacción de Subversion.

  2. Realice sus cambios (adiciones, borrados, modificación de propiedades, etc.).

  3. 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.

Figura 8.1. Ficheros y directorios en dos dimensiones

Ficheros y directorios en dos dimensiones

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.

Figura 8.2. Versionando el tiempo—¡la tercera dimensión!

Versionando el tiempo—¡la tercera dimensión!

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:

  1. crear, abrir, destruir y realizar los pasos de recuperación sobre un repositorio Subversion y el sistema de ficheros incluido en el mismo.

  2. describir las diferencias entre dos árboles de sistema de ficheros.

  3. 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.

  4. generar un volcado legible por un humano del sistema de ficheros, una representación completa de las revisiones en el sistema de ficheros.

  5. 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.

Capa de acceso al repositorio

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

RA-DAV (Acceso al repositorio usando HTTP/DAV)

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.

RA-SVN (Acceso al repositorio usando protocolo propio)

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.

RA-Local (Acceso directo al repositorio)

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.

Su librería RA aquí

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.

Capa cliente

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.