SVNBOOK Chap8 Layered Library Design
De Framalang Wiki.
Cette page fait partie du projet Version control with subversion.
| Pseudo | Code | Rôle | Statut |
|---|---|---|---|
| Hotshot92 | Traduction | Fait | |
| SVF | 1ère Relecture | Fait | |
| Validation |
Source : http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.developer.layerlib
Sommaire |
Layered Library Design
Each of Subversion's core libraries can be said to exist in one of three main layers—the Repository layer, the Repository Access (RA) layer, or the Client layer (see Figure 1, “Subversion's architecture” in the Preface). We will examine these layers shortly, but first, let's briefly summarize Subversion's various libraries. For the sake of consistency, we will refer to the libraries by their extensionless Unix library names (libsvn_fs, libsvn_wc, mod_dav_svn, etc.).
libsvn_client
- Primary interface for client programs
libsvn_delta
- Tree and byte-stream differencing routines
libsvn_diff
- Contextual differencing and merging routines
libsvn_fs
- Filesystem commons and module loader
libsvn_fs_base
- The Berkeley DB filesystem backend
libsvn_fs_fs
- The native filesystem (FSFS) backend
libsvn_ra
- Repository Access commons and module loader
libsvn_ra_local
- The local Repository Access module
libsvn_ra_neon
- The WebDAV Repository Access module
libsvn_ra_serf
- Another (experimental) WebDAV Repository Access module
libsvn_ra_svn
- The custom protocol Repository Access module
libsvn_repos
- Repository interface
libsvn_subr
- Miscellaneous helpful subroutines
libsvn_wc
- The working copy management library
mod_authz_svn
- Apache authorization module for Subversion repositories access via WebDAV
mod_dav_svn
- Apache module for mapping WebDAV operations to Subversion ones
Chaque bibliothèque au sein de Subversion peut être classée dans une des trois couches principales — la couche dépôt, la couche d'accès au dépôt (RA pour "repository access" en anglais) et la couche client (voir la figure 1, "Architecture de Subversion" de la préface). Nous allons examiner ces trois couches rapidement mais, d'abord, passons brièvement en revue les différentes bibliothèques de Subversion. Pour des raisons de cohérence, nous nous référerons à ces bibliothèques par leurs noms Unix sans extension (libsvn_fs, libsvn_wc, mod_dav_svn, etc.).
- libsvn_client
- interface principale pour les programmes clients ;
- libsvn_delta
- routines de recherche de différences pour les arborescences et les flux d'octets ;
- libsvn_diff
- routines de recherche de différences et de fusions contextuelles ;
- libsvn_fs
- chargeur de modules et outils communs pour le système de fichiers ;
- libsvn_fs_base
- gestion du magasin de données Berkeley DB ;
- libsvn_fs_fs
- gestion du magasin de données natif FSFS ;
- libsvn_ra
- outils communs pour l'accès au dépôt et chargeur de modules ;
- libsvn_ra_local
- module d'accès au dépôt en local ;
- libsvn_ra_neon
- module d'accès au dépôt par WebDAV ;
- libsvn_ra_serf
- autre module (expérimental) d'accès au dépôt par WebDAV ;
- libsvn_ra_svn
- modèle d'accès au dépôt par le protocole Subversion ;
- libsvn_repos
- interface du dépôt ;
- libsvn_subr
- diverses routines utiles ;
- libsvn_wc
- bibliothèque pour la gestion de la copie de travail local ;
- mod_authz_svn
- module Apache d'authentification pour les accès aux dépôts Subversion par WebDAV ;
- mod_dav_svn
- module Apache de correspondance entre les opérations WebDAV et les opérations Subversion.
The fact that the word “miscellaneous” appears only once in the previous list is a good sign. The Subversion development team is serious about making sure that functionality lives in the right layer and libraries. Perhaps the greatest advantage of the modular design is its lack of complexity from a developer's point of view. As a developer, you can quickly formulate that kind of “big picture” that allows you to pinpoint the location of certain pieces of functionality with relative ease.
Another benefit of modularity is the ability to replace a given module with a whole new library that implements the same API without affecting the rest of the code base. In some sense, this happens within Subversion already. The libsvn_ra_local, libsvn_ra_neon, libsvn_ra_serf, and libsvn_ra_svn libraries each implement the same interface, all working as plug-ins to libsvn_ra. And all four communicate with the Repository layer—libsvn_ra_local connects to the repository directly; the other three do so over a network. The libsvn_fs_base and libsvn_fs_fs libraries are another pair of libraries that implement the same functionality in different ways—both are plug-ins to the common libsvn_fs library.
The client itself also highlights the benefits of modularity in the Subversion design. Subversion's libsvn_client library is a one-stop shop for most of the functionality necessary for designing a working Subversion client (see the section called “Client Layer”). So while the Subversion distribution provides only the svn command-line client program, several third-party programs provide various forms of graphical client UIs. These GUIs use the same APIs that the stock command-line client does. This type of modularity has played a large role in the proliferation of available Subversion clients and IDE integrations and, by extension, to the tremendous adoption rate of Subversion itself.
Le fait que le mot "divers" n'apparaisse qu'une seule fois dans la liste précédente est bon signe. L'équipe de développement de Subversion est particulièrement soucieuse de placer les fonctionnalités dans les couches et bibliothèques appropriées. Un des plus grands avantages de cette conception modulaire, du point de vue du développeur, est sûrement l'absence de complexité. En tant que développeur, vous pouvez vous forger rapidement une image mentale de cette architecture et ainsi trouver relativement facilement l'emplacement des fonctionnalités qui vous intéressent.
Un autre avantage de la modularité est la possibilité de remplacer un module par une autre bibliothèque qui implémente la même API sans affecter le reste du code. Dans un certain sens, c'est ce qui se passe déjà dans Subversion. Les bibliothèques libsvn_ra_local, libsvn_ra_neon, libsvn_ra_serf et libsvn_ra_svn implémentent toutes la même interface et fonctionnent comme des greffons pour libsvn_ra. Et toutes les quatre communiquent avec la couche dépôt — libsvn_ra_local se connectant directement au dépôt, les trois autres le faisant à travers le réseau. Libsvn_fs_base et libsvn_fs_fs sont un autre exemple de bibliothèques qui implémentent les mêmes fonctionnalités de différentes manières — les deux sont des greffons pour la bibliothèque commune libsvn_fs.
Le client lui-même illustre également les avantages de la modularité dans l'architecture de Subversion. La bibliothèque libsvn_client est un point d'entrée unique pour la plupart des fonctionnalités nécessaires à la conception d'un client Subversion qui fonctionne (voir la section intitulée "Couche client"). Ainsi, bien que la distribution Subversion fournisse seulement le programme en ligne de commande svn, de nombreux programmes tiers fournissent différents types d'IHM. Ces interfaces graphiques utilisent la même API que le client en ligne de commande fourni en standard. Depuis le début, cette modularité joue un rôle majeur dans la prolifération des différents clients Subversion (sous la forme de clients autonomes ou greffés dans des environnements de développement intégrés [IDE en anglais]) et, par extension, dans l'adoption formidablement rapide de Subversion lui-même.
Repository Layer
When referring to Subversion's Repository layer, we're generally talking about two basic concepts—the versioned filesystem implementation (accessed via libsvn_fs, and supported by its libsvn_fs_base and libsvn_fs_fs plug-ins), and the repository logic that wraps it (as implemented in libsvn_repos). These libraries provide the storage and reporting mechanisms for the various revisions of your version-controlled data. This layer is connected to the Client layer via the Repository Access layer, and is, from the perspective of the Subversion user, the stuff at the “other end of the line.”
The Subversion filesystem is not a kernel-level filesystem that one would install in an operating system (such as the Linux ext2 or NTFS), but instead is a virtual filesystem. Rather than storing “files” and “directories” as real files and directories (the kind you can navigate through using your favorite shell program), it uses one of two available abstract storage backends—either a Berkeley DB database environment or a flat-file representation. (To learn more about the two repository backends, see the section called “Choosing a Data Store”.) There has even been considerable interest by the development community in giving future releases of Subversion the ability to use other backend database systems, perhaps through a mechanism such as Open Database Connectivity (ODBC). In fact, Google did something similar to this before launching the Google Code Project Hosting service: they announced in mid-2006 that members of its open source team had written a new proprietary Subversion filesystem plug-in that used Google's ultra-scalable Bigtable database for its storage.
Quand nous faisons référence à la couche dépôt de Subversion, nous parlons généralement de deux concepts de base : l'implémentation du système de fichiers suivi en versions (auquel on a accès via libsvn_fs et qui est supporté par les greffons associés libsvn_fs_base et libsvn_fs_fs) et la logique du dépôt qui l'habille (telle qu'elle est implémentée dans libsvn_repos). Ces bibliothèques fournissent les mécanismes de stockage et de comptes-rendus pour les différentes révisions de vos données suivies en versions. Cette couche est connectée à la couche client via la couche d'accès au dépôt et est, du point de vue de l'utilisateur de Subversion, le "truc à l'autre bout de la ligne".
Le système de fichiers Subversion n'est pas un système de fichiers de bas niveau que vous pourriez installer sur votre système d'exploitation (tels que NTFS ou ext2 pour Linux) mais un système de fichiers virtuel. Plutôt que de stocker les fichiers et répertoires comme des fichiers et des répertoires réels (du type de ceux dans lesquels vous naviguez avec votre navigateur de fichiers), il utilise un des deux magasins de données abstraits disponibles : soit le système de gestion de bases de données Berkeley DB soit une représentation dans des fichiers ordinaires, dite "à plat" (pour en apprendre plus sur les deux magasins de données, reportez-vous à la section intitulée "Choisir un magasin de données"). La communauté de développement Subversion a même exprimé le souhait que les futures versions de Subversion puissent utiliser d'autres magasins de données, peut-être à travers un mécanisme tel que ODBC (Open Database Connectivity , standard ouvert de connexion à des bases de données). En fait, Google a fait quelque chose de semblable avant de lancer le service "Google Code Project Hosting" (Hébergement de code source de projets) : ils ont annoncé mi-2006 que les membres de leur équipe open source avaient écrit un nouveau greffon propriétaire de système de fichiers pour Subversion, qui utilisait leur base de données "Google ultra-scalable Bigtable" comme magasin de données.
The filesystem API exported by libsvn_fs contains the kinds of functionality you would expect from any other filesystem API—you can create and remove files and directories, copy and move them around, modify file contents, and so on. It also has features that are not quite as common, such as the ability to add, modify, and remove metadata (“properties”) on each file or directory. Furthermore, the Subversion filesystem is a versioning filesystem, which means that as you make changes to your directory tree, Subversion remembers what your tree looked like before those changes. And before the previous changes. And the previous ones. And so on, all the way back through versioning time to (and just beyond) the moment you first started adding things to the filesystem.
All the modifications you make to your tree are done within the context of a Subversion commit transaction. The following is a simplified general routine for modifying your filesystem:
- 1. Begin a Subversion commit transaction.
- 2. Make your changes (adds, deletes, property modifications, etc.).
- 3. Commit your transaction.
Once you have committed your transaction, your filesystem modifications are permanently stored as historical artifacts. Each of these cycles generates a single new revision of your tree, and each revision is forever accessible as an immutable snapshot of “the way things were.”
L'API du système de fichiers, mise à disposition par libsvn_fs, contient les fonctionnalités que vous pouvez attendre de n'importe quel autre système de fichiers : vous pouvez créer et supprimer des fichiers et des répertoires, les copier et les déplacer, modifier le contenu d'un fichier, etc. Elle possède également des caractéristiques peu communes comme la capacité d'ajouter, modifier et supprimer des méta-données ("propriétés") sur chaque fichier ou répertoire. En outre, le système de fichiers Subversion est un système de fichiers suivi en version, ce qui veut dire que si vous faites des modifications dans votre arborescence, Subversion se souvient de l'état de votre arborescence avant les modifications. Et il se souvient aussi de l'état avant les modifications précédentes, et l'état encore antérieur, et ainsi de suite. Vous pouvez ainsi remonter le temps (c'est-à-dire les versions) jusqu'au moment où vous avez commencé à ajouter des éléments dans le système de fichiers.
Toutes les modifications que vous faites sur votre arborescence ont pour contexte les transactions de propagation de Subversion. Ce qui suit est la démarche générale simplifiée de modification de votre système de fichiers :
- 1. Commencer une transaction de propagation de Subversion ;
- 2. Effectuer vos modifications (ajouts, suppressions, modifications de propriétés, etc.)
- 3. Propager votre transaction.
Une fois que vous avez propagé votre transaction, les modifications de votre système de fichiers sont stockées de façon permanente en tant qu'éléments de l'historique. Chacun de ces cycles génère une nouvelle révision de votre arborescence, et chaque révision est accessible pour toujours sous la forme d'un cliché, immuable, de l'état de l'arborescence à un moment précis.
POINT OF INTEREST : The Transaction Distraction
- The Transaction Distraction
- Digression sur les transactions
- The notion of a Subversion transaction can become easily confused with the transaction support provided by the underlying database itself, especially given the former's close proximity to the Berkeley DB database code in libsvn_fs_base. Both types of transaction exist to provide atomicity and isolation. In other words, transactions give you the ability to perform a set of actions in an all-or-nothing fashion—either all the actions in the set complete with success, or they all get treated as though none of them ever happened—and in a way that does not interfere with other processes acting on the data.
- Database transactions generally encompass small operations related specifically to the modification of data in the database itself (such as changing the contents of a table row). Subversion transactions are larger in scope, encompassing higher-level operations such as making modifications to a set of files and directories that are intended to be stored as the next revision of the filesystem tree. If that isn't confusing enough, consider the fact that Subversion uses a database transaction during the creation of a Subversion transaction (so that if the creation of a Subversion transaction fails, the database will look as though we had never attempted that creation in the first place)!
- Fortunately for users of the filesystem API, the transaction support provided by the database system itself is hidden almost entirely from view (as should be expected from a properly modularized library scheme). It is only when you start digging into the implementation of the filesystem itself that such things become visible (or interesting).
- La notion de transaction Subversion peut être facilement confondue avec la notion de transaction concernant le magasin de données sous-jacent, en particulier à cause de la proximité du code des transactions Subversion dans libsvn_fs_base et du code du gestionnaire de bases de données Berkeley DB. Ces deux types de transactions assurent l'atomicité et l'isolation. En d'autres termes, les transactions vous permettent d'effectuer un ensemble d'actions avec une logique tout-ou-rien (soit toutes les actions de l'ensemble se terminent avec succès, soit c'est comme si aucune n'avait eu lieu), ce qui permet de ne pas interférer avec les autres processus qui travaillent sur les données.
- Les transactions dans les bases de données comprennent généralement de petites opérations relatives à la modification de données dans la base elle-même (comme changer le contenu d'une ligne dans une table). Les transactions Subversion ont un champ d'action plus large, elles comprennent des opérations de plus haut niveau telles que modifier un ensemble de fichiers et de répertoires qui doivent être stockés dans la prochaine révision de l'arborescence suivie en versions. Pour ajouter à la confusion, Subversion utilise une transaction de base de données pendant la création d'une transaction Subversion (ainsi, si la création de la transaction Subversion échoue, la base de données sera telle que si la demande de création n'avait jamais eu lieu) !
- Heureusement pour les utilisateurs de l'API du système de fichiers, la notion de transaction du système de gestion de bases de données lui-même est presque entièrement masquée (comme on peut s'y attendre dans une architecture modulaire bien construite). C'est seulement si vous commencez à fouiller dans l'implémentation du système de fichiers que de telles choses deviennent visibles (ou intéressantes).
Most of the functionality the filesystem interface provides deals with actions that occur on individual filesystem paths. That is, from outside the filesystem, the primary mechanism for describing and accessing the individual revisions of files and directories comes through the use of path strings such as /foo/bar, just as though you were addressing files and directories through your favorite shell program. You add new files and directories by passing their paths-to-be to the right API functions. You query for information about them by the same mechanism.
Unlike most filesystems, though, a path alone is not enough information to identify a file or directory in Subversion. Think of a directory tree as a two-dimensional system, where a node's siblings represent a sort of left-and-right motion, and navigating into the node's subdirectories represents a downward motion. Figure 8.1, “Files and directories in two dimensions” shows a typical representation of a tree as exactly that.
La majeure partie des fonctionnalités offertes par l'interface du système de fichiers traite d'actions relatives à un chemin unique du système de fichiers. C'est-à-dire que, vu de l'extérieur du système de fichiers, le mécanisme de base pour décrire et accéder à une révision donnée d'un fichier ou d'un répertoire utilise des chemins classiques tels que /machin/bidule, de la même manière que quand vous indiquez un fichier ou un répertoire dans votre interface en ligne de commande favorite. Vous ajoutez de nouveaux fichiers ou répertoires en passant leur "futur" chemin à la fonction idoine de l'API. Vous faites des requêtes sur ces éléments avec le même mécanisme.
Cependant, contrairement à la plupart des systèmes de fichiers, le chemin n'est pas une information suffisante pour identifier un fichier ou un répertoire dans Subversion. Représentez-vous l'arborescence des répertoires comme un système à deux dimensions, où on atteint les frères d'un nœud en se déplaçant horizontalement, à droite ou à gauche, et où la navigation dans les sous-répertoires de ce nœud peut être assimilée à un mouvement vers le bas. La figure 8.1 "Fichiers et répertoires en deux dimensions" illustre ce concept pour une arborescence classique.The difference here is that the Subversion filesystem has a nifty third dimension that most filesystems do not have—Time! [52] In the filesystem interface, nearly every function that has a path argument also expects a root argument. This svn_fs_root_t argument describes either a revision or a Subversion transaction (which is simply a revision in the making) and provides that third dimension of context needed to understand the difference between /foo/bar in revision 32, and the same path as it exists in revision 98. Figure 8.2, “Versioning time—the third dimension!” shows revision history as an added dimension to the Subversion filesystem universe.
As we mentioned earlier, the libsvn_fs API looks and feels like any other filesystem, except that it has this wonderful versioning capability. It was designed to be usable by any program interested in a versioning filesystem. Not coincidentally, Subversion itself is interested in that functionality. But while the filesystem API should be sufficient for basic file and directory versioning support, Subversion wants more—and that is where libsvn_repos comes in.
The Subversion repository library (libsvn_repos) sits (logically speaking) atop the libsvn_fs API, providing additional functionality beyond that of the underlying versioned filesystem logic. It does not completely wrap each and every filesystem function—only certain major steps in the general cycle of filesystem activity are wrapped by the repository interface. Some of these include the creation and commit of Subversion transactions and the modification of revision properties. These particular events are wrapped by the repository layer because they have hooks associated with them. A repository hook system is not strictly related to implementing a versioning filesystem, so it lives in the repository wrapper library.
Comme nous l'avons déjà mentionné, l'API de libsvn_fs ressemble à s'y méprendre à celle de n'importe quel autre système de fichiers, sauf qu'on y a ajouté la formidable capacité de suivre les versions. Elle a été conçue pour être utilisable par n'importe quel programme ayant besoin d'un système de fichiers suivi en versions. Et, ce n'est pas un hasard, Subversion lui-même est intéressé par une telle fonctionnalité. Mais, bien que cette API soit suffisante pour effectuer un suivi en versions basique des fichiers et des répertoires, Subversion en demande plus, et c'est là que libsvn_repos entre en scène.
La bibliothèque du dépôt Subversion (libsvn_repos) se situe (logiquement parlant) au-dessus de l'API libsvn_fs et elle fournit des fonctionnalités supplémentaires allant au-delà de la logique sous-jacente du système de fichiers suivi en versions. Elle ne masque pas entièrement chaque fonction du système de fichiers — seules certaines étapes importantes dans le cycle général de l'activité du système de fichiers sont encapsulées par l'interface du dépôt. Parmi les fonctions encapsulées, on peut citer la création et la propagation des transactions Subversion et la modification des propriétés de révisions. Ces actions particulières sont encapsulées par la couche dépôt parce qu'elles ont des procédures automatiques associées. Le système des procédures automatiques du dépôt n'est pas strictement concomitant à l'implémentation d'un système de fichiers suivi en versions, c'est pourquoi il réside dans la bibliothèque d'encapsulation du dépôt.
The hooks mechanism is but one of the reasons for the abstraction of a separate repository library from the rest of the filesystem code. The libsvn_repos API provides several other important utilities to Subversion. These include the abilities to:
- Create, open, destroy, and perform recovery steps on a Subversion repository and the filesystem included in that repository.
- Describe the differences between two filesystem trees.
- Query for the commit log messages associated with all (or some) of the revisions in which a set of files was modified in the filesystem.
- Generate a human-readable “dump” of the filesystem—a complete representation of the revisions in the filesystem.
- Parse that dump format, loading the dumped revisions into a different Subversion repository.
As Subversion continues to evolve, the repository library will grow with the filesystem library to offer increased functionality and configurable option support.
Le mécanisme des procédures automatiques n'est pas l'unique raison qui a conduit à séparer logiquement la bibliothèque du dépôt du reste du code du système de fichiers. L'API de libsvn_repos fournit à Subversion un certain nombre d'autres possibilités intéressantes. Parmi elles, on peut citer :
- créer, ouvrir, détruire et effectuer des actions de restauration sur un dépôt Subversion et le système de fichiers inclus dans ce dépôt ;
- décrire les différences entre deux arborescences ;
- obtenir les messages de propagation associés à toutes (ou certaines) les révisions qui ont modifié un ensemble de fichiers du système de fichiers ;
- générer des images ("dumps") du système de fichiers lisibles par un humain — ces images étant des représentations complètes des révisions du système de fichiers ;
- analyser ces images, et les charger dans un autre dépôt Subversion.
Repository Access Layer
If the Subversion Repository layer is at “the other end of the line,” the Repository Access (RA) layer is the line itself. Charged with marshaling data between the client libraries and the repository, this layer includes the libsvn_ra module loader library, the RA modules themselves (which currently includes libsvn_ra_neon, libsvn_ra_local, libsvn_ra_serf, and libsvn_ra_svn), and any additional libraries needed by one or more of those RA modules (such as the mod_dav_svn Apache module or libsvn_ra_svn's server, svnserve).
Since Subversion uses URLs to identify its repository resources, the protocol portion of the URL scheme (usually file://, http://, https://, svn://, or svn+ssh://) is used to determine which RA module will handle the communications. Each module registers a list of the protocols it knows how to “speak” so that the RA loader can, at runtime, determine which module to use for the task at hand. You can determine which RA modules are available to the Subversion command-line client, and what protocols they claim to support, by running svn --version:
Si la couche Dépôt de Subversion est "à l'autre bout de la ligne", la couche d'accès au dépôt (RA pour "repository access" en anglais) est la ligne en tant que telle. Chargée d'organiser les données entre les bibliothèques client et le dépôt, cette couche inclut la bibliothèque de chargement du module libsvn_ra, les modules RA eux-mêmes (qui incluent à l'heure actuelle libsvn_ra_neon, libsvn_ra_local, libsvn_ra_serf et libsvn_ra_svn) et toute bibliothèque supplémentaire requise par un ou plusieurs de ces modules RA (par exemple, le module Apache mod_dav_svn ou le serveur de libsvn_ra_svn, svnserve).
Comme Subversion utilise les URL pour identifier les dépôts à contacter, la partie de l'URL qui indique le protocole (habituellement file://, http://, https://, svn:// ou svn+ssh://) est utilisée pour déterminer quel module RA gérera les communications. Chaque module indique la liste des protocoles qu'il connaît afin que le chargeur RA puisse déterminer, à l'exécution, quel module utiliser pour la tâche en cours. Vous pouvez obtenir la liste des modules RA disponibles pour votre client Subversion en ligne de commande, ainsi que les protocoles qu'ils prennent en charge, en lançant la commande svn --version :
$ svn --version svn, version 1.5.0 (r31699) compiled Jun 18 2008, 09:57:36 Copyright (C) 2000-2008 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_neon : Module for accessing a repository via WebDAV protocol using Neon. - handles 'http' scheme - handles 'https' scheme * ra_svn : Module for accessing a repository using the svn network protocol. - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme $
$ svn --version
svn, version 1.5.0 (r31699)
compilé Jun 18 2008, 09:57:36
Copyright (C) 2000-2008 CollabNet.
Subversion est un logiciel libre, cf http://subversion.tigris.org/
Il inclut du logiciel développé par CollabNet (http://www.Collab.Net/).
Les modules d'accès à un dépôt (RA) suivants sont disponibles :
* ra_neon : Module d'accès à un dépôt via le protocole WebDAV avec Neon.
- gère le schéma d'URL 'http'
- gère le schéma d'URL 'https'
* ra_svn : Module d'accès à un dépôt avec le protocole réseau propre de svn.
- avec authentification Cyrus SASL
- gère le schéma d'URL 'svn'
* ra_local : Module d'accès à un dépôt sur un disque local.
- gère le schéma d'URL 'file'
* ra_serf : Module d'accès à un dépôt via le protocole WebDAV avec serf.
- gère le schéma d'URL 'http'
- gère le schéma d'URL 'https'
The public API exported by the RA layer contains functionality necessary for sending and receiving versioned data to and from the repository. And each of the available RA plug-ins is able to perform that task using a specific protocol—libsvn_ra_dav speaks HTTP/WebDAV (optionally using SSL encryption) with an Apache HTTP Server that is running the mod_dav_svn Subversion server module; libsvn_ra_svn speaks a custom network protocol with the svnserve program; and so on.
For those who wish to access a Subversion repository using still another protocol, that is precisely why the Repository Access layer is modularized! Developers can simply write a new library that implements the RA interface on one side and communicates with the repository on the other. Your new library can use existing network protocols or you can invent your own. You could use interprocess communication (IPC) calls, or—let's get crazy, shall we?—you could even implement an email-based protocol. Subversion supplies the APIs; you supply the creativity.
L'API publique exportée par la couche RA contient les fonctionnalités nécessaires pour envoyer des données suivies en version vers le dépôt, et pour en recevoir. Chacun des greffons RA disponibles est capable d'effectuer ces tâches en utilisant un protocole particulier : libsvn_ra_dav utilise le protocole HTTP/WebDAV (avec chiffrement SSL en option) pour communiquer avec un serveur HTTP Apache sur lequel fonctionne le module serveur Subversion mod_dav_svn ; libsvn_ra_svn utilise un protocole réseau propre à Subversion pour communiquer avec le programme svnserve, et ainsi de suite.
Ceux qui désirent accéder à un dépôt Subversion en utilisant un autre protocole comprendront rapidement pourquoi la couche d'accès au dépôt est modulaire ! Les développeurs peuvent tout simplement écrire une nouvelle bibliothèque qui implémente l'interface RA d'un côté et qui communique avec le dépôt de l'autre. Votre nouvelle bibliothèque peut utiliser des protocoles réseaux existants ou vous pouvez en inventer un nouveau. Vous pourriez ainsi utiliser les communications inter-processus (IPC pour "interprocess communication" en anglais) ou même, soyons fou, implémenter un protocole basé sur l'email. Subversion apporte les API, à vous d'apporter la créativité.
Client Layer
On the client side, the Subversion working copy is where all the action takes place. The bulk of functionality implemented by the client-side libraries exists for the sole purpose of managing working copies—directories full of files and other subdirectories that serve as a sort of local, editable “reflection” of one or more repository locations—and propagating changes to and from the Repository Access layer.
Subversion's working copy library, libsvn_wc, is directly responsible for managing the data in the working copies. To accomplish this, the library stores administrative information about each working copy directory within a special subdirectory. This subdirectory, named .svn, is present in each working copy directory and contains various other files and directories that record state and provide a private workspace for administrative action. For those familiar with CVS, this .svn subdirectory is similar in purpose to the CVS administrative directories found in CVS working copies. For more information about the .svn administrative area, see the section called “Inside the Working Copy Administration Area” later in this chapter.
Côté client, la copie de travail Subversion est l'endroit où tout se passe. Le gros des fonctionnalités implémentées par les bibliothèques client existe dans le seul but de gérer les copies de travail locales — des répertoires pleins de fichiers et d'autres sous-répertoires qui sont une sorte de copie locale et modifiable d'un ou plusieurs dépôts — et de propager les changements vers et depuis la couche d'accès au dépôt.
La bibliothèque de Subversion pour la copie de travail, libsvn_wc, est directement responsable de la gestion des données dans les copies de travail. Pour ce faire, la bibliothèque stocke des données d'administration à propos de chaque répertoire suivi en versions dans un sous-répertoire spécial. Ce sous-répertoire, nommé .svn, est présent dans chaque répertoire d'une copie de travail ; il contient tout un tas de fichiers et de répertoires qui enregistrent l'état du répertoire suivi en versions et fournit un espace privé pour les actions d'administration. Pour les habitués de CVS, ce sous-répertoire .svn a des objectifs similaires aux répertoires administratifs CVS que l'on trouve dans les copies de travail CVS. Pour plus d'informations sur la zone d'administration .svn, reportez-vous à la section intitulée "Au cœur de la zone d'administration de la copie de travail" plus loin dans ce chapitre.
The Subversion client library, libsvn_client, has the broadest responsibility; its job is to mingle the functionality of the working copy library with that of the Repository Access layer, and then to provide the highest-level API to any application that wishes to perform general revision control actions. For example, the function svn_client_checkout() takes a URL as an argument. It passes this URL to the RA layer and opens an authenticated session with a particular repository. It then asks the repository for a certain tree, and sends this tree into the working copy library, which then writes a full working copy to disk (.svn directories and all).
The client library is designed to be used by any application. While the Subversion source code includes a standard command-line client, it should be very easy to write any number of GUI clients on top of the client library. New GUIs (or any new client, really) for Subversion need not be clunky wrappers around the included command-line client—they have full access via the libsvn_client API to the same functionality, data, and callback mechanisms that the command-line client uses. In fact, the Subversion source code tree contains a small C program (which you can find at tools/examples/minimal_client.c) that exemplifies how to wield the Subversion API to create a simple client program.
La bibliothèque client de Subversion, libsvn_client, est celle qui a le plus de responsabilités : son rôle est de mélanger les fonctionnalités de la bibliothèque de la copie de travail avec celles de la couche d'accès au dépôt (RA) afin de fournir l'API de plus haut niveau, utilisable par n'importe quelle application qui voudrait effectuer des actions générales de suivi de versions. Par exemple, la fonction svn_client_checkout() prend une URL en argument. Elle passe cette URL à la couche RA et ouvre une session authentifiée avec le dépôt concerné. Elle demande ensuite au dépôt l'arborescence requise, envoie cette arborescence à la bibliothèque de la copie de travail, qui écrit alors une copie de travail complète sur le disque (les répertoires .svn et tout).
La bibliothèque client est conçue pour être utilisée par n'importe quelle application. Alors que le code source de Subversion inclut un client standard en ligne de commande, il doit être très facile d'écrire un nombre quelconque de clients utilisant une interface utilisateur graphique (GUI en anglais) par dessus cette bibliothèque client. Les nouvelles GUI (ou les nouveaux clients en fait) pour Subversion n'ont aucune raison de n'être que des sur-couches au client en ligne de commande : elles ont un accès total, via l'API libsvn_client, aux mêmes fonctionnalités, données et autres mécanismes que le client en ligne de commande utilise. En fait, le code source de Subversion contient un petit programme en C (que vous pouvez trouver dans tools/examples/minimal_client.c) qui montre comment utiliser en pratique l'API Subversion pour créer un programme client simple.POINT OF INTEREST : Binding Directly—A Word About Correctness
- Binding Directly—A Word About Correctness
- Un mot sur la pertinence d'utiliser directement les bibliothèques
- Why should your GUI program bind directly with a libsvn_client instead of acting as a wrapper around a command-line program? Besides simply being more efficient, it can be more correct as well. A command-line program (such as the one supplied with Subversion) that binds to the client library needs to effectively translate feedback and requested data bits from C types to some form of human-readable output. This type of translation can be lossy. That is, the program may not display all of the information harvested from the API or may combine bits of information for compact representation.
- If you wrap such a command-line program with yet another program, the second program has access only to already interpreted (and as we mentioned, likely incomplete) information, which it must again translate into its representation format. With each layer of wrapping, the integrity of the original data is potentially tainted more and more, much like the result of making a copy of a copy (of a copy…) of a favorite audio or video cassette.
- But the most compelling argument for binding directly to the APIs instead of wrapping other programs is that the Subversion project makes compatibility promises regarding its APIs. Across minor versions of those APIs (such as between 1.3 and 1.4), no function's prototype will change. In other words, you aren't forced to update your program's source code simply because you've upgraded to a new version of Subversion. Certain functions might be deprecated, but they still work, and this gives you a buffer of time to eventually embrace the newer APIs. These kinds of compatibility promises do not exist for Subversion command-line program output, which is subject to change from release to release.
- Pourquoi utiliser directement libsvn_client pour votre interface graphique plutôt que d'encapsuler le programme en ligne de commande ? À part le fait que c'est plus efficace, c'est également plus correct. Un programme en ligne de commande (tel que celui fourni avec Subversion) qui utilise la bibliothèque client a besoin de traduire effectivement des requêtes et des réponses contenues dans des variables en C en un affichage lisible par un humain. Ce type de traduction peut induire des pertes. C'est-à-dire que le programme n'affichera peut-être pas l'ensemble des informations qu'il a obtenu de l'API ou alors qu'il combinera peut-être certaines informations pour obtenir une représentation plus compacte.
- Si vous encapsulez le programme en ligne de commande avec un autre programme, cette sur-couche n'aura accès qu'à des informations déjà interprétées (et, comme nous venons de le mentionner, potentiellement incomplètes) et elle devra une nouvelle fois traduire ces informations vers son propre format de représentation des données. À chaque couche d'encapsulation supplémentaire, l'intégrité des données originales s'effrite un peu plus, à la manière d'une copie de copie (de copie ...) d'une cassette audio ou vidéo.
- Mais l'argument décisif quant à l'utilisation directe des API plutôt que d'encapsuler d'autres programmes est que le projet Subversion assure la compatibilité vis-à-vis de ses API. Lors des changements de versions mineurs des API (comme par exemple entre la version 1.3 et 1.4), aucun prototype de fonction ne change. En d'autres termes, vous n'êtes pas forcé de mettre à jour le code source de votre programme simplement parce que vous avez mis à jour votre version de Subversion. Certaines fonctions seront peut-être obsolètes, mais elles fonctionneront toujours. Ainsi, cela vous laisse de la marge pour éventuellement adopter les nouvelles API. Ce type de promesse de compatibilité n'existe pas pour les sorties du programme Subversion en ligne de commande, qui est susceptible de changer à chaque version.
