Définition d'un dépôt Subversion

Définition d'un dépôt Subversion
Précédent	Chapitre 5. Administration d'un dépôt	Suivant

Avant d'aborder le vaste sujet de l'administration d'un dépôt, définissons plus précisément ce qu'est un dépôt. À quoi ressemble-t-il ? Que ressent-il ? Est-ce qu'il préfère son thé chaud ou glacé, sucré, avec une tranche de citron ? En tant qu'administrateur, vous vous devez de comprendre de quoi est composé un dépôt, à la fois au niveau du système d'exploitation (à quoi ressemble le dépôt et comment il réagit vis-à-vis des outils autres que Subversion) et au niveau logique de l'organisation des données (comment elles sont représentées à l'intérieur du dépôt).

Du point de vue d'un explorateur de fichiers classique (comme Windows Explorer) ou d'un outil de navigation du système de fichiers en ligne de commande, un dépôt Subversion n'est rien d'autre qu'un répertoire contenant plein de choses. Il y a des sous-dossiers avec des fichiers de configuration lisibles par un humain, des sous-dossiers avec des fichiers de données binaires déjà bien moins lisibles, etc. À l'instar d'autres parties de Subversion, la modularité est une préoccupation majeure et l'organisation hiérarchique prévaut sur le bazar. Ainsi, un rapide coup d'œil dans un dépôt ordinaire est suffisant pour obtenir la liste des composants essentiels d'un dépôt :

$ ls dépot
conf/  db/  format  hooks/  locks/  README.txt

Effectuons un survol rapide de ce que nous voyons dans ce répertoire (ne vous inquiétez pas si vous ne comprenez pas tous les termes employés, ils sont expliqués dans ce chapitre ou ailleurs dans ce livre) :

conf/: Un dossier destiné à accueillir les fichiers de configuration.
db/: Le magasin de données pour toutes vos données suivies en versions^[49].
format: Ce fichier décrit le schéma d'organisation interne du dépôt. Il se trouve que le sous-dossier db contient parfois aussi un fichier format qui ne décrit que le contenu de ce sous-dossier et ne doit pas être confondu avec ce fichier.
hooks/: Ce dossier contient les modèles de procédures automatiques (et les procédures automatiques elles-mêmes, une fois installées).
locks/: Ce répertoire est utilisé pour les fichiers de verrous du dépôt Subversion, de façon à gérer les accès concurrents au dépôt.
README.txt: Un petit fichier qui ne fait qu'informer son lecteur qu'il se trouve dans un dépôt Subversion.

Note

	Note
Avant Subversion 1.5, la structure du dépôt sur le disque contenait toujours un sous-dossier `dav`. `mod_dav_svn` utilisait ce dossier pour stocker des informations relatives aux activités WEBDAV (l'équivalent haut-niveau du protocole WebDAV au concept de transaction dans les propagations Subversion). Subversion 1.5 a modifié cette situation en transférant la propriété du dossier activités et la possibilité de configurer son emplacement à `mod_dav_svn` lui-même. Dorénavant, les dépôts ne possèdent pas nécessairement un sous-dossier `dav`, à moins que vous n'utilisiez `mod_dav_svn` et que vous ne l'ayez pas configuré afin qu'il place la base de données relative à ses activités ailleurs. Reportez-vous à la section intitulée « Directives de configuration de mod_dav_svn » pour plus d'informations.

Avant Subversion 1.5, la structure du dépôt sur le disque contenait toujours un sous-dossier dav. mod_dav_svn utilisait ce dossier pour stocker des informations relatives aux activités WEBDAV (l'équivalent haut-niveau du protocole WebDAV au concept de transaction dans les propagations Subversion). Subversion 1.5 a modifié cette situation en transférant la propriété du dossier activités et la possibilité de configurer son emplacement à mod_dav_svn lui-même. Dorénavant, les dépôts ne possèdent pas nécessairement un sous-dossier dav, à moins que vous n'utilisiez mod_dav_svn et que vous ne l'ayez pas configuré afin qu'il place la base de données relative à ses activités ailleurs. Reportez-vous à la section intitulée « Directives de configuration de mod_dav_svn » pour plus d'informations.

Bien sûr, quand on y accède via les bibliothèques Subversion, cet ensemble de fichiers et de dossiers se transforme en un système de fichiers suivis en versions virtuel, complet et comportant une gestion des événements personnalisable. Ce système de fichiers possède ses propres notions de répertoires et de fichiers, très similaires aux notions des systèmes de fichiers réels (tels que NTFS, FAT32, ext3, etc.). Mais c'est un système de fichiers spécial : il base ces répertoires et ces fichiers sur les révisions, conservant l'historique de tous les changements effectués de manière sûre et pérenne. C'est là que la totalité de vos données suivies en versions réside.

À propos des magasins de données

Lors de la conception initiale de Subversion, les développeurs ont décidé d'utiliser le gestionnaire de bases de données Berkeley DB pour tout un tas de raisons, entre autres sa licence Open Source, son support des transactions, sa fiabilité, ses performances, la simplicité de son interface de programmation (API), le bon support des processus légers (threads), le support des curseurs, etc.

Le temps passant, un nouveau magasin de données^[50], dénommé FSFS^[51] a fait son apparition. Ce que l'on pourrait appeler « le système de fichiers du système de fichiers » était un système de fichiers suivis en versions. Cependant, il utilise le système de fichiers natif du système d'exploitation directement plutôt que le côté obscur d'une base de données. FSFS a fait l'objet d'améliorations et de développement en continu, ce qui lui a permis finalement de devenir le magasin de données par défaut de Subversion. Les améliorations se sont toujours poursuivies et, en fin de compte, la couche de stockage FSFS a surpassé Berkeley DB dans presque toutes les caractéristiques significatives, de la performance à la fiabilité en passant par la capacité à monter en charge.

De nos jours, on considère en général que si vous utilisez le produit standard Subversion, les magasins de données de vos dépôts sont au format FSFS. En fait, à partir de Subversion 1.8, le magasin Berkeley DB est officiellement obsolète. Les dépôts qui utilisent toujours ce magasin continueront à fonctionner avec les nouvelles versions Subversion 1.x, mais aucun développement (ce qui inclut l'ajout de fonctionnalités ou d'extensions) n'est planifié pour le magasin Berkeley DB. Subversion ne promeut qu'un seul magasin de données pour les dépôts : FSFS.

Ce livre continue à fournir les informations nécessaires aux administrateurs de magasins BDB autant que nécessaire, mais une grande partie de ce chapitre considère que, à l'instar du reste du monde, FSFS est le magasin de données de Subversion. Reportez-vous à Annexe D, Le système de fichiers Berkeley DB ou à d'anciennes versions de la documentation pour obtenir des informations complètes quant à l'administration de tels dépôts.

^[49]Strictement parlant, Subversion n'oblige pas à ce que les données suivies en versions soient stockées ici et il existe des variantes (quoique propriétaires) de stockage des données qui ne stockent pas réellement leurs données dans ce dossier.

^[50]NdT : souvent désigné par backend en anglais (sans équivalent en français) ou, ce qui peut être source de confusion, « le système de fichiers) »

^[51]Souvent prononcé « feuzz-feuzz » par Jack Repenning (ce livre, cependant, suppose que le lecteur pense « eff-ess-eff-ess »).

Précédent	Niveau supérieur	Suivant
Chapitre 5. Administration d'un dépôt	Sommaire	Stratégies de déploiement d'un dépôt