This text is a work in progress—highly subject to change—and may not accurately describe any released version of the Apache™ Subversion® software. Bookmarking or otherwise referring others to this page is probably not such a smart idea. Please visit http://www.svnbook.com/ for stable versions of this book.

Stratégies de déploiement d'un dépôt

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 :

Dans cette section, nous essayons de vous aider à répondre à ces questions.

Stratégies d'organisation d'un dépôt

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[50].

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 dossier qui héberge les principaux développements du projet ; branches, le dossier 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)[51].

Par exemple, votre dépôt peut ressembler à ceci :


/
   calc/
      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
      calc/
         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/
      calc/
      calendrier/
      tableur/
      …
   tags/
      calc/
      calendrier/
      tableur/
      …
   branches/
      calc/
      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 connait 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.

Stratégies d'hébergement d'un dépôt

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 (nous le verrons à la prochaine section), 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.

Choix du magasin de données

Subversion offre deux types de stockage interne pour le magasin de données[52] 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[53] — 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, en général, les programmes qui accèdent aux dépôts Subversion ignore 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.

Berkeley DB

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[54], la plupart des systèmes de fichiers en réseau et des systèmes dédiés n'atteint 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 souvent le principal intérêt d'un dépôt accessible sur un partage réseau).

[Avertissement] 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, dispose 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] 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.

FSFS

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 » à l'instar d'un dépôt BDB.

Les fichiers de révision FSFS décrivent la structure des répertoires de révision, le contenu des fichiers et les deltas vis-à-vis des autres arborescences à d'autres révisions. Contrairement aux bases de données Berkeley DB, ce format de stockage est portable entre différents systèmes d'exploitation et est indifférent à l'architecture du processeur. Comme aucun fichier de journalisation ou de mémoire partagée n'est utilisé, le répertoire peut être accédé sans problème depuis un système de fichiers en réseau et peut être consulté dans un environnement en lecture seule. L'absence de zone propre à une base de donnée permet également d'obtenir une taille de dépôt légèrement plus petite.

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 est plus lent à la fin d'une propagation, faisant des tâches que le magasin BDB effectue tout au long de la propagation, ce qui peut conduire dans des cas extrêmes à ce que les clients considèrent que la requête a expiré avant qu'ils ne recoivent de 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.



[50] 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.

[51] Le trio trunk, tags et branches est quelquefois appelé « les répertoires TTB » (the TTB directories en anglais).

[52] 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) »

[53] Souvent prononcé « feuzz-feuzz » si Jack Repenning en parle (ce livre, cependant, suppose que le lecteur pense « eff-ess-eff-ess »).

[54] 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.