En grande partie grâce à la conception épurée du dépôt Subversion et des technologies sous-jacentes, il est particulièrement aisé de créer et configurer un dépôt. Il y a quelques choix préliminaires à faire mais l'essentiel du travail de création et de configuration d'un dépôt Subversion est simple et convivial, facilement reproductible si vous êtes amené à effectuer des installations multiples.
Voici quelques questions à se poser avant toute chose :
-
Quelles données vont être hébergées dans le dépôt (ou les dépôts) et quelle en sera l'organisation ?
-
Où sera placé le dépôt et comment les utilisateurs y accéderont-ils ?
-
De quels types de contrôle d'accès et de notifications d'événements avez-vous besoin ?
-
Quel type de magasin de données désirez-vous utiliser ?
Dans cette section, nous essayons de vous aider à répondre à ces questions.
Bien que Subversion vous permette de déplacer des fichiers et des répertoires suivis en versions sans perte d'information et qu'il fournisse même des outils pour déplacer des ensembles complets de données suivies en version d'un dépôt à un autre, ces opérations peuvent perturber le travail des autres collaborateurs qui accèdent souvent au dépôt et qui s'attendent à trouver chaque chose à sa place. Ainsi, avant de créer un nouveau dépôt, essayez de vous projeter un peu dans le futur ; préparez à l'avance le passage de vos données sous gestion de versions. Cette réflexion sur la manière d'organiser vos données dans le dépôt vous évitera de futurs et nombreux maux de tête.
Supposons qu'en tant qu'administrateur d'un dépôt, vous êtes responsable de l'administration du système de gestion de versions pour plusieurs projets. La première décision à prendre est de choisir entre un seul dépôt pour tous les projets et un dépôt par projet, ou bien un compromis entre ces deux solutions.
Un seul dépôt pour tous les projets offre des avantages, ne serait-ce que pour la maintenance unifiée. Un seul dépôt signifie qu'il n'y a qu'un seul jeu de procédures automatiques, une seule sauvegarde à gérer, un seul jeu d'opérations de déchargement et de chargement à effectuer si la nouvelle version de Subversion est incompatible avec l'ancienne version, etc. Vous pouvez également déplacer facilement des données entre les projets, sans perdre l'historique de ces informations.
Les inconvénients à utiliser un seul dépôt sont que les différents projets auront certainement des besoins différents en termes de gestion des événements, comme la notification par e-mail des propagations à des listes d'adresses différentes ou des définitions différentes de ce qui constitue une propagation légitime. Bien sûr, ce ne sont pas des problèmes insurmontables — cela implique juste que vos procédures automatiques doivent tenir compte de l'organisation du dépôt dans lequel elles sont invoquées plutôt que de considérer que l'ensemble du dépôt est associé à un seul groupe d'utilisateurs. Rappelez-vous également que Subversion utilise des numéros de révisions globaux au dépôt. Bien que ces numéros ne possèdent pas de pouvoirs magiques particuliers, certaines personnes n'aiment pas voir le numéro de révision augmenter alors qu'elles n'ont pas touché à leur propre projet[28].
On peut aussi adopter une approche intermédiaire. Par exemple, les projets peuvent être regroupés par thème. Vous pouvez avoir quelques dépôts, avec une poignée de projets dans chaque dépôt. Ainsi, les projets susceptibles de partager des données le font aisément et les développeurs sont tenus au courant des avancées des projets en relation avec les leurs par le biais des nouvelles révisions du dépôt.
Une fois l'organisation des dépôts définie, il faut se
préoccuper de la hiérarchie des répertoires à l'intérieur des
dépôts eux-mêmes. Comme Subversion utilise de simples copies de
répertoires pour créer les branches et les étiquettes (voir le
Chapitre 4, Gestion des branches), la communauté Subversion
recommande de choisir un endroit dans le dépôt pour la
racine de chaque projet (le répertoire
dont la sous-arborescence contient toutes les données relatives
à un projet) et d'y placer trois sous-répertoires :
trunk (« tronc » en français),
le répertoire qui héberge les principaux développements
du projet ; branches, le répertoire
dans lequel seront créées les différentes variations de la
ligne de développement principale ; et
tags (« étiquettes » en
français), qui contient un ensemble d'instantanés de
l'arborescence (les instantanés sont créés, voire détruits, mais
jamais modifiés)[29].
Par exemple, votre dépôt peut ressembler à ceci :
/
calculatrice/
trunk/
tags/
branches/
calendrier/
trunk/
tags/
branches/
tableur/
trunk/
tags/
branches/
…
Veuillez noter que l'emplacement du projet dans le dépôt n'est pas important. Si vous n'avez qu'un seul projet par dépôt, il est logique de placer la racine du projet à la racine du dépôt correspondant. Si vous avez plusieurs projets, vous voulez peut-être les classer par groupes dans des sous-répertoires communs du dépôt, en fonction des objectifs ou du code à partager par exemple, ou tout simplement en les groupant par ordre alphabétique. Voici un exemple :
/
utilitaires/
calculatrice/
trunk/
tags/
branches/
calendrier/
trunk/
tags/
branches/
…
bureautique/
tableur/
trunk/
tags/
branches/
…
Organisez votre dépôt comme vous le sentez. Subversion n'a aucune exigence en la matière — pour lui, un répertoire est un répertoire. L'objectif est d'avoir une organisation qui réponde aux besoins des collaborateurs des différents projets.
Cependant, par souci de transparence, nous indiquons une
autre organisation également très répandue. Dans cette
organisation, les répertoires trunk,
tags et branches sont
situés à la racine du dépôt et les projets sont placés dans des
sous-répertoires juste en dessous, comme ceci :
/
trunk/
calculatrice/
calendrier/
tableur/
…
tags/
calculatrice/
calendrier/
tableur/
…
branches/
calculatrice/
calendrier/
tableur/
…
Il n'y a rien d'incorrect dans une telle organisation, mais elle peut ne pas être très intuitive pour vos utilisateurs. En particulier dans des situations complexes avec plusieurs projets et un grand nombre d'utilisateurs, dont la plupart ne connaissent qu'un ou deux projets du dépôt. Mais cette approche « plusieurs projets par branche » a tendance à favoriser l'ouverture de chaque projet sur les autres et pousse à envisager l'ensemble des projets comme une seule entité. Cela reste un problème social. Nous aimons l'organisation suggérée au début pour des raisons purement pratiques : il est plus facile de faire des requêtes (ou des modifications, des migrations) sur l'historique complet d'un projet quand une sous-arborescence du dépôt contient l'ensemble des données (passé, présent, étiquettes et branches) de ce projet et elles seules.
Avant de créer votre dépôt Subversion, vous devez vous demander où il va résider. Cette question est fortement liée à une myriade d'autres questions telles que : qui sont les utilisateurs (sont-ils à l'intérieur de votre réseau interne, derrière le pare-feu de votre entreprise, ou bien s'agit-il de n'importe qui, n'importe où sur Internet ?), comment les utilisateurs accèdent au dépôt (via un serveur Subversion ou directement), quels autres services vous fournissez autour de Subversion (une interface pour navigateur Web, des notifications par email des propagations, etc.), quelle est votre politique de sauvegarde et ainsi de suite.
Le choix et la configuration du serveur sont abordés au Chapitre 6, Configuration du serveur, mais nous voulons signaler dès maintenant que certains choix pour l'une ou l'autre de ces questions ont des implications sur l'endroit où implémenter votre serveur. Par exemple, certains scénarios de déploiement nécessitent, pour plusieurs ordinateurs, l'accès au dépôt via un système de fichiers distant et, dans ce cas, le choix du type de magasin de données n'en est plus un, puisqu'un seul type de magasin de données convient dans ce scénario.
Décrire l'ensemble des possibilités de déploiement de Subversion est impossible et n'est pas l'objectif de ce livre. Nous vous encourageons simplement à évaluer vos choix avec ces quelques pages ainsi qu'avec d'autres ressources en guise de référence afin de planifier correctement les opérations.
Depuis la version 1.1, Subversion offre deux types de stockage interne pour le magasin de données[30] utilisé par le dépôt. Un des types de magasin de données conserve tout dans une base de données Berkeley DB (ou BDB) ; les dépôts qui utilisent ce type de magasin sont qualifiés de « dépôts gérés par BDB » ou « dépôts BDB ». L'autre type de magasin stocke les données dans des fichiers ordinaires, en utilisant un format particulier. Les développeurs de Subversion ont pris l'habitude d'appeler ce type de stockage FSFS[31] — une implémentation d'un système de fichiers suivis en versions qui utilise le système de fichiers natif du système d'exploitation directement plutôt que par l'intermédiaire d'une bibliothèque de gestionnaire de base de données ou toute autre couche d'abstraction.
Une comparaison des dépôts utilisant Berkeley DB et FSFS fait l'objet du Tableau 5.1, « Comparaison des magasins de données de dépôts ».
Tableau 5.1. Comparaison des magasins de données de dépôts
| Catégorie | Fonctionnalité | Berkeley DB | FSFS |
|---|---|---|---|
| Fiabilité | Intégrité des données | Très fiable quand déployé correctement ; Berkeley DB 4.4 apporte l'auto-restauration | Les vieilles versions avaient quelques bogues (rarement démontrés) qui détruisaient des données |
| Sensibilité aux interruptions | Forte ; les « plantages » et les problèmes de droits peuvent laisser la base de données dans un état instable, nécessitant le recours aux procédures de restauration issues de la journalisation | Quasiment insensible | |
| Accessibilité | Utilisable depuis un montage en lecture seule | Non | Oui |
| Stockage indépendant de la plateforme | Non | Oui | |
| Utilisable sur des systèmes de fichiers en réseau | Généralement non | Oui | |
| Gestion des droits pour les groupes | Sensible aux problèmes de umask de l'utilisateur ; c'est mieux si un seul utilisateur y accède | Contourne les problèmes de umask | |
| Extensibilité | Utilisation des disques sur le dépôt | Plus grande (surtout si les fichiers de journalisation ne sont pas purgés) | Plus faible |
| Nombre de révisions | Base de données, pas de problème | De vieux systèmes de fichiers fonctionnent moins bien lorsqu'il y a plusieurs milliers d'entrées dans un seul répertoire | |
| Répertoires avec beaucoup de fichiers | Plus lent | Plus rapide | |
| Performances | Extraire la dernière révision | Pas de différence significative | Pas de différence significative |
| Grosses propagations | Globalement plus lent, mais mais cette lenteur est répartie sur toute la durée de la propagation | Globalement plus rapide, mais le délai de finalisation peut amener le client à considérer que sa requête a expiré avant qu'il ne reçoive la réponse |
Chaque type de magasin de données a ses avantages et ses inconvénients. Aucun n'est plus « officiel » que l'autre, même si le nouveau FSFS est le magasin par défaut depuis Subversion 1.2. Les deux sont suffisamment fiables pour y stocker vos données suivies en versions en toute confiance. Mais comme l'indique le Tableau 5.1, « Comparaison des magasins de données de dépôts », FSFS est un peu plus souple à déployer. Plus de souplesse signifie que vous devez y mettre un peu plus du vôtre pour faire des erreurs lors du déploiement. C'est pourquoi, en plus du fait que ne pas utiliser Berkeley DB permet de compter un composant de moins dans le système, aujourd'hui, presque tout le monde utilise FSFS lors de la création de nouveaux dépôts.
Heureusement, la plupart des programmes qui accèdent aux dépôts Subversion ignorent royalement quel type de magasin de données est utilisé. Et vous n'êtes même pas prisonnier de votre premier choix de magasin : si vous changez d'avis plus tard, Subversion offre différentes façons de migrer les données de votre dépôt dans un autre dépôt utilisant un magasin de données différent. Nous en reparlons plus loin dans ce chapitre.
Les paragraphes suivants abordent plus en détail les différents types de magasins de données disponibles.
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 gestionnaire de bases de données Berkeley DB apporte un support réel des transactions (c'est peut-être sa fonctionnalité la plus puissante). Si de nombreux processus accèdent en même temps au dépôt, ils n'ont pas à se soucier d'éventuelles corruptions de données de la part des autres processus. L'isolement créé par le système de transaction est tel que, pour une opération donnée, Subversion voit une base de données statique — pas une base de données en perpétuel changement en raison des autres processus — et peut donc prendre des décisions à partir de cette perspective. Si la décision entraîne un conflit avec ce que fait un autre processus, l'opération complète est annulée, tout se passe comme si elle n'avait jamais eu lieu et Subversion essaie une nouvelle fois son opération sur la base de données mise à jour (qui apparaît toujours statique).
Une autre fonctionnalité phare du gestionnaire de bases de données Berkeley DB est la sauvegarde à chaud — la capacité de sauvegarder l'environnement de la base de données sans la couper du réseau. Nous voyons comment réaliser une sauvegarde de votre dépôt plus loin dans ce chapitre (dans la section intitulée « Sauvegarde d'un dépôt »), mais le bénéfice de pouvoir faire des copies opérationnelles de vos dépôts sans interruption de service doit vous sauter aux yeux.
Le gestionnaire de bases de données Berkeley DB est aussi très fiable quand il est utilisé correctement. Subversion utilise les fonctions de journalisation du gestionnaire de bases de données Berkeley DB, ce qui veut dire que la base de données consigne d'abord dans un fichier de journalisation situé sur disque chaque modification qu'elle s'apprête à effectuer, puis effectue la modification elle-même. Cela garantit que si quelque chose se passe mal, le gestionnaire de base de données peut revenir à un point de contrôle précédent — un point précis des fichiers de journalisation dont il sait qu'il n'est pas corrompu — et rejouer les transactions jusqu'à ce que les données soient dans un état opérationnel. Voir la section intitulée « Gestion de l'espace disque » plus loin dans ce chapitre pour plus de détails sur les fichiers de journalisation Berkeley DB.
Mais chaque médaille à son revers et nous devons vous avertir de quelques limitations du gestionnaire de bases de données Berkeley DB. Premièrement, les environnements du gestionnaire de bases de données Berkeley DB ne sont pas portables. Vous ne pouvez pas simplement copier un dépôt Subversion qui a été créé sur un système Unix vers un système Windows et espérer qu'il fonctionne. Bien que la majeure partie de la base de données Berkeley DB soit indépendante de l'architecture, d'autres aspects de l'environnement ne le sont pas. Deuxièmement, Subversion utilise le gestionnaire de bases de données Berkeley DB de telle façon que cela ne fonctionne pas sur un système Windows 95/98 : si vous avez besoin d'héberger un dépôt géré par BDB sur une machine Windows, adoptez Windows 2000 ou plus.
Alors que le gestionnaire de bases de données Berkeley DB prétend fonctionner correctement sur un système de fichiers en réseau, pour peu que celui-ci respecte des caractéristiques particulières[32], la plupart des systèmes de fichiers en réseau et des systèmes dédiés n'atteignent pas ces pré-requis. Et en aucun cas il ne vous est possible de partager ce dépôt sur un système de fichiers en réseau entre plusieurs clients (alors que c'est quand même l'intérêt principal d'un dépôt accessible sur un partage réseau).
![[Avertissement]](images/warning.png)
|
Avertissement |
|---|---|
|
Si vous tentez d'utiliser le gestionnaire de bases de données Berkeley DB sur un système de fichiers en réseau non compatible, les résultats sont imprévisibles : vous vous apercevrez peut-être immédiatement de mystérieuses erreurs, mais il se peut qu'il se passe des mois avant que vous ne découvriez que votre base de données de dépôt est corrompue. Songez sérieusement à utiliser un magasin FSFS pour les dépôts qui doivent être hébergés sur un partage réseau. |
Finalement, parce que la bibliothèque du gestionnaire de bases de données Berkeley DB est directement incluse dans Subversion, elle est plus sensible aux interruptions qu'une base de données relationnelle classique. La plupart des systèmes SQL, par exemple, disposent d'un processus serveur dédié qui coordonne tous les accès aux tables. Si un programme qui accède aux tables plante pour une raison ou une autre, le processus serveur de la base de données s'en aperçoit et fait le ménage. Et comme le processus serveur est le seul processus accédant réellement aux tables, les applications n'ont pas à se soucier des conflits de droits. Cependant, ce n'est pas le cas avec le gestionnaire de bases de données Berkeley DB. Subversion (et les programmes utilisant les bibliothèques de Subversion) accèdent aux tables directement, ce qui veut dire que le plantage d'un programme peut laisser la base de données dans un état temporairement incohérent et inaccessible. Quand cela arrive, un administrateur doit demander au gestionnaire de bases de données Berkeley DB de revenir à un point de contrôle, ce qui est assez ennuyeux. D'autres incidents peuvent faire planter la base de données, comme des conflits entre programmes pour la possession ou les droits sur les fichiers de la base de données.
![[Note]](images/note.png)
|
Note |
|---|---|
|
La version 4.4 du gestionnaire de bases de données Berkeley DB permet à Subversion (version 1.4 ou plus) de restaurer un environnement Berkeley DB automatiquement et de manière transparente en cas de besoin. Quand un processus Subversion se greffe sur l'environnement d'un dépôt Berkeley DB, il utilise un mécanisme d'enregistrement pour détecter d'éventuels problèmes de déconnexion antérieurs , effectue les restaurations nécessaires puis passe à la suite comme si de rien n'était. Cela n'élimine pas complètement les plantages du dépôt, mais les actions humaines nécessaires pour revenir à une situation normale sont considérablement réduites. |
Ainsi, bien qu'un dépôt Berkeley DB soit rapide et capable
de monter en puissance, il faut privilégier une utilisation
par un seul processus serveur tournant avec une identité
unique (comme les serveurs Apache httpd
ou svnserve : voir le Chapitre 6, Configuration du serveur) à un accès par de
nombreux utilisateurs via des URL file://
ou svn+ssh://. Si de multiples utilisateurs
doivent avoir accès à un dépôt Berkeley DB, lisez
la section intitulée « Accès au dépôt par plusieurs méthodes » plus loin dans
ce chapitre.
Mi-2004, un deuxième type de stockage pour le dépôt, qui ne fait pas appel à une base de données, a fait son apparition. Un dépôt FSFS stocke les changements associés à une révision dans un fichier unique, ce qui fait que l'ensemble des révisions du dépôt se trouvent dans un seul sous-répertoire rempli de fichiers numérotés. Les transactions sont créées, en tant que fichiers individuels, dans des sous-répertoires séparés. Une fois la transaction terminée, le fichier de transaction est renommé et placé dans le répertoire des révisions, ce qui garantit l'atomicité des propagations. Et puisqu'un fichier de révision est permanent et non modifiable, le dépôt peut également être sauvegardé « à chaud » comme un dépôt BDB.
Les fichiers de révision FSFS décrivent, pour une révision donnée, la structure des répertoires, le contenu des fichiers et les deltas entre les fichiers et les autres arborescences de révisions. Contrairement à une base de données Berkeley DB, le format de stockage est portable, transférable entre différents systèmes d'exploitation et n'est pas sensible à l'architecture CPU. Comme il n'y a pas de journalisation ou de fichiers en mémoire partagée, le dépôt est accessible sans risque via un partage de fichiers sur le réseau ou depuis un environnement en lecture seule. L'absence des en-têtes liés à une base de données réduit aussi quelque peu la taille globale du dépôt.
FSF diffère également du point de vue des performances. Quand vous propagez un répertoire comptant un nombre de fichiers très élevé, FSFS est capable d'ajouter plus rapidement les éléments du répertoire. D'un autre côté, FSFS écrit la dernière version d'un fichier sous forme de delta par rapport à la version précédente, par conséquent une extraction de l'arborescence la plus récente est un peu plus lente que l'obtention des fichiers entiers stockés dans la révision HEAD d'une base de données Berkeley DB. FSFS est également plus long lors de la fin de la propagation, ce qui peut amener le client à considérer, dans des cas extrêmes, que sa requête a expiré avant qu'il ne reçoive la réponse.
La différence la plus importante reste quand même la résistance aux plantages lorsque quelque chose va mal. Si un processus qui utilise une base de données Berkeley DB rencontre un problème de droits ou plante soudainement, la base de données risque de se retrouver dans un état instable jusqu'à ce qu'un administrateur la restaure. Si la même chose arrive à un processus utilisant un dépôt FSFS, le dépôt n'est en rien affecté. Au pire, quelques données de transaction sont égarées.
Le seul véritable argument contre FSFS est sa relative immaturité face à Berkeley DB. Berkeley DB a une histoire de plusieurs années, avec une équipe de développement dédiée et, aujourd'hui, il est adossé à la toute-puissante marque Oracle[33]. FSFS est de conception plus récente. Avant la version 1.4 de Subversion apparaissaient de temps en temps quelques bogues assez sérieux concernant l'intégrité des données qui, bien que n'arrivant que dans de très rares cas, étaient bien réels. Ceci dit, FSFS est rapidement devenu le magasin de données de référence pour quelques-uns des plus vastes dépôts Subversion publics et privés et il promet de rendre globalement plus facile le passage à Subversion.
[28] Que ce soit par ignorance ou par la définition absurde de métriques de développement, les numéros globaux de révision sont craints alors qu'ils sont bien peu de chose et certainement pas à prendre en considération quand vous décidez de l'agencement de vos projets et de vos dépôts.
[29] Le trio trunk,
tags et branches
est quelquefois appelé « les répertoires TTB »
(the TTB directories
en anglais).
[30] 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 (suivi en versions) »
[31] Souvent prononcé « feuzz-feuzz » si Jack Repenning en parle (ce livre, cependant, suppose que le lecteur pense « eff-ess-eff-ess »).
[32] Berkeley DB requiert que le système de fichiers sous-jacent implémente strictement la sémantique POSIX sur les verrous et, plus important encore, la possibilité de projeter les fichiers directement en mémoire vive.
[33] Oracle a acheté Sleepycat et son logiciel vedette, Berkeley DB, le jour de la Saint Valentin 2006.