SVNBOOK Chap5 Strategies for Repository Deployment
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 |
Sommaire |
Strategies for Repository Deployment
Due largely to the simplicity of the overall design of the Subversion repository and the technologies on which it relies, creating and configuring a repository are fairly straightforward tasks. There are a few preliminary decisions you'll want to make, but the actual work involved in any given setup of a Subversion repository is pretty basic, tending toward mindless repetition if you find yourself setting up multiples of these things.
Some things you'll want to consider beforehand, though, are:
- What data do you expect to live in your repository (or repositories), and how will that data be organized?
- Where will your repository live, and how will it be accessed?
- What types of access control and repository event reporting do you need?
- Which of the available types of data store do you want to use?
In this section, we'll try to help you answer those questions.
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 allons essayer de vous aider à répondre à ces questions.
Planning Your Repository Organization
While Subversion allows you to move around versioned files and directories without any loss of information, and even provides ways of moving whole sets of versioned history from one repository to another, doing so can greatly disrupt the workflow of those who access the repository often and come to expect things to be at certain locations. So before creating a new repository, try to peer into the future a bit; plan ahead before placing your data under version control. By conscientiously “laying out” your repository or repositories and their versioned contents ahead of time, you can prevent many future headaches.
Bien que Subversion vous permette de déplacer des fichiers et des répertoires suivis en versions sans perte d'information, et fournisse même des outils pour déplacer des ensembles complets de données versionnées 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 en suivi 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.
Paragraphe
Let's assume that as repository administrator, you will be responsible for supporting the version control system for several projects. Your first decision is whether to use a single repository for multiple projects, or to give each project its own repository, or some compromise of these two.
There are benefits to using a single repository for multiple projects, most obviously the lack of duplicated maintenance. A single repository means that there is one set of hook programs, one thing to routinely back up, one thing to dump and load if Subversion releases an incompatible new version, and so on. Also, you can move data between projects easily, without losing any historical versioning information.
The downside of using a single repository is that different projects may have different requirements in terms of the repository event triggers, such as needing to send commit notification emails to different mailing lists, or having different definitions about what does and does not constitute a legitimate commit. These aren't insurmountable problems, of course—it just means that all of your hook scripts have to be sensitive to the layout of your repository rather than assuming that the whole repository is associated with a single group of people. Also, remember that Subversion uses repository-global revision numbers. While those numbers don't have any particular magical powers, some folks still don't like the fact that even though no changes have been made to their project lately, the youngest revision number for the repository keeps climbing because other projects are actively adding new revisions. [27]
Supposons qu'en tant qu'administrateur d'un dépôt, vous serez 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 devront tenir compte de l'organisation du dépôt dans lequel ils sont invoqués 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'ils n'ont pas touché à leur propre projet [27].
Paragraphe
A middle-ground approach can be taken, too. For example, projects can be grouped by how well they relate to each other. You might have a few repositories with a handful of projects in each repository. That way, projects that are likely to want to share data can do so easily, and as new revisions are added to the repository, at least the developers know that those new revisions are at least remotely related to everyone who uses that repository.
After deciding how to organize your projects with respect to repositories, you'll probably want to think about directory hierarchies within the repositories themselves. Because Subversion uses regular directory copies for branching and tagging (see Chapter 4, Branching and Merging), the Subversion community recommends that you choose a repository location for each project root—the “topmost” directory that contains data related to that project—and then create three subdirectories beneath that root: trunk, meaning the directory under which the main project development occurs; branches, which is a directory in which to create various named branches of the main development line; and tags, which is a collection of tree snapshots that are created, and perhaps destroyed, but never changed. [28]
On peut aussi adopter une approche intermédiaire. Par exemple, les projets peuvent être regroupés par thème. Vous pourriez 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 ; 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 pas modifiés [28]).
For example, your repository might look like this:
/
calc/
trunk/
tags/
branches/
calendar/
trunk/
tags/
branches/
spreadsheet/
trunk/
tags/
branches/
…
Par exemple, votre dépôt pourrait ressembler à ceci :
/
calculatrice/
trunk/
tags/
branches/
calendrier/
trunk/
tags/
branches/
tableur/
trunk/
tags/
branches/
…
Note that it doesn't matter where in your repository each project root is. If you have only one project per repository, the logical place to put each project root is at the root of that project's respective repository. If you have multiple projects, you might want to arrange them in groups inside the repository, perhaps putting projects with similar goals or shared code in the same subdirectory, or maybe just grouping them alphabetically. Such an arrangement might look like this:
/
utils/
calc/
trunk/
tags/
branches/
calendar/
trunk/
tags/
branches/
…
office/
spreadsheet/
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 voudrez 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/
…
Lay out your repository in whatever way you see fit. Subversion does not expect or enforce a particular layout—in its eyes, a directory is a directory is a directory. Ultimately, you should choose the repository arrangement that meets the needs of the people who work on the projects that live there.
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.
In the name of full disclosure, though, we'll mention another very common layout. In this layout, the trunk, tags, and branches directories live in the root directory of your repository, and your projects are in subdirectories beneath those, like so:
/
trunk/
calc/
calendar/
spreadsheet/
…
tags/
calc/
calendar/
spreadsheet/
…
branches/
calc/
calendar/
spreadsheet/
…
Cependant, par souci de transparence, nous signalerons 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/
…
There's nothing particularly incorrect about such a layout, but it may or may not seem as intuitive for your users. Especially in large, multiproject situations with many users, those users may tend to be familiar with only one or two of the projects in the repository. But the projects-as-branch-siblings approach tends to deemphasize project individuality and focus on the entire set of projects as a single entity. That's a social issue, though. We like our originally suggested arrangement for purely practical reasons—it's easier to ask about (or modify, or migrate elsewhere) the entire history of a single project when there's a single repository path that holds the entire history—past, present, tagged, and branched—for that project and that project alone.
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.
Deciding Where and How to Host Your Repository
Before creating your Subversion repository, an obvious question you'll need to answer is where the thing is going to live. This is strongly connected to myriad other questions involving how the repository will be accessed (via a Subversion server or directly), by whom (users behind your corporate firewall or the whole world out on the open Internet), what other services you'll be providing around Subversion (repository browsing interfaces, email-based commit notification, etc.), your data backup strategy, and so on.
Avant de créer votre dépôt Subversion, vous devrez vous demander où il va résider. C'est fortement lié à 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éderont au dépôt (via un serveur Subversion ou directement), quels autres services fournirez-vous autour de Subversion (une interface pour navigateur Web, des notifications par mail des propagations, etc.), quelle sera votre politique de sauvegarde, et ainsi de suite.
We cover server choice and configuration in Chapter 6, Server Configuration, but the point we'd like to briefly make here is simply that the answers to some of these other questions might have implications that force your hand when deciding where your repository will live. For example, certain deployment scenarios might require accessing the repository via a remote filesystem from multiple computers, in which case (as you'll read in the next section) your choice of a repository backend data store turns out not to be a choice at all because only one of the available backends will work in this scenario.
Le choix et la configuration du serveur seront 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 l'accès au dépôt via un système de fichiers distant pour plusieurs ordinateurs 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.
Addressing each possible way to deploy Subversion is both impossible and outside the scope of this book. We simply encourage you to evaluate your options using these pages and other sources as your reference material and to plan ahead.
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 et d'autres ressources en guise de référence pour planifier correctement les opérations.
Choosing a Data Store
As of version 1.1, Subversion provides two options for the type of underlying data store—often referred to as “the backend” or, somewhat confusingly, “the (versioned) filesystem”—that each repository uses. One type of data store keeps everything in a Berkeley DB (or BDB) database environment; repositories that use this type are often referred to as being “BDB-backed.” The other type stores data in ordinary flat files, using a custom format. Subversion developers have adopted the habit of referring to this latter data storage mechanism as FSFS [29] —a versioned filesystem implementation that uses the native OS filesystem directly—rather than via a database library or some other abstraction layer—to store data.
Table 5.1, “Repository data store comparison” gives a comparative overview of Berkeley DB and FSFS repositories.
Depuis la version 1.1, Subversion offre deux types de stockage interne pour le magasin de données - 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 (versionné)" - 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 seront 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 [29] - 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.
Le tableau 5.1 "Comparaison des magasins de données de dépôts" offre une présentation comparée des dépôts utilisant Berkeley DB et FSFS.
| Category | Feature | Berkeley DB | FSFS |
|---|---|---|---|
| Reliability | Data integrity | When properly deployed, extremely reliable; Berkeley DB 4.4 brings auto-recovery | Older versions had some rarely demonstrated, but data-destroying bugs |
| Sensitivity to interruptions | Very; crashes and permission problems can leave the database “wedged,” requiring journaled recovery procedures | Quite insensitive | |
| Accessibility | Usable from a read-only mount | No | Yes |
| Platform-independent storage | No | Yes | |
| Usable over network filesystems | Generally, no | Yes | |
| Group permissions handling | Sensitive to user umask problems; best if accessed by only one user | Works around umask problems | |
| Scalability | Repository disk usage | Larger (especially if logfiles aren't purged) | Smaller |
| Number of revision trees | Database; no problems | Some older native filesystems don't scale well with thousands of entries in a single directory | |
| Directories with many files | Slower | Faster | |
| Performance | Checking out latest revision | No meaningful difference | No meaningful difference |
| Large commits | Slower overall, but cost is amortized across the lifetime of the commit | Faster overall, but finalization delay may cause client timeouts |
| 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 plate-forme | 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 (particulièrement 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 |
There are advantages and disadvantages to each of these two backend types. Neither of them is more “official” than the other, though the newer FSFS is the default data store as of Subversion 1.2. Both are reliable enough to trust with your versioned data. But as you can see in Table 5.1, “Repository data store comparison”, the FSFS backend provides quite a bit more flexibility in terms of its supported deployment scenarios. More flexibility means you have to work a little harder to find ways to deploy it incorrectly. Those reasons—plus the fact that not using Berkeley DB means there's one fewer component in the system—largely explain why today almost everyone uses the FSFS backend when creating new repositories.
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 devrez 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.
Fortunately, most programs that access Subversion repositories are blissfully ignorant of which backend data store is in use. And you aren't even necessarily stuck with your first choice of a data store—in the event that you change your mind later, Subversion provides ways of migrating your repository's data into another repository that uses a different backend data store. We talk more about that later in this chapter.
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 : au cas où vous changeriez 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 reparlerons plus loin dans ce chapitre.
The following subsections provide a more detailed look at the available backend data store types.
Les paragraphes suivants abordent plus en détail les différents types de magasins de données disponibles.
Berkeley DB
When the initial design phase of Subversion was in progress, the developers decided to use Berkeley DB for a variety of reasons, including its open source license, transaction support, reliability, performance, API simplicity, thread safety, support for cursors, and so on.
Berkeley DB provides real transaction support—perhaps its most powerful feature. Multiple processes accessing your Subversion repositories don't have to worry about accidentally clobbering each other's data. The isolation provided by the transaction system is such that for any given operation, the Subversion repository code sees a static view of the database—not a database that is constantly changing at the hand of some other process—and can make decisions based on that view. If the decision made happens to conflict with what another process is doing, the entire operation is rolled back as though it never happened, and Subversion gracefully retries the operation against a new, updated (and yet still static) view of the database.
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).
Another great feature of Berkeley DB is hot backups—the ability to back up the database environment without taking it “offline.” We'll discuss how to back up your repository later in this chapter (in the section called “Repository Backup”), but the benefits of being able to make fully functional copies of your repositories without any downtime should be obvious.
Berkeley DB is also a very reliable database system when properly used. Subversion uses Berkeley DB's logging facilities, which means that the database first writes to on-disk logfiles a description of any modifications it is about to make, and then makes the modification itself. This is to ensure that if anything goes wrong, the database system can back up to a previous checkpoint—a location in the logfiles known not to be corrupt—and replay transactions until the data is restored to a usable state. See the section called “Managing Disk Space” later in this chapter for more about Berkeley DB logfiles.
Une autre fonctionnalité phare du gestionnaire de bases de données Berkeley DB est la sauvegarde à chaud : la capacité de sauvegarde de l'environnement de la base de données sans la couper du réseau. Nous verrons comment réaliser une sauvegarde de votre dépôt plus tard dans ce chapitre (dans la section "Sauvegarde du 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 "Gestion de l'espace disque" plus loin dans ce chapitre pour plus de détails sur les fichiers de journalisation Berkeley DB.
But every rose has its thorn, and so we must note some known limitations of Berkeley DB. First, Berkeley DB environments are not portable. You cannot simply copy a Subversion repository that was created on a Unix system onto a Windows system and expect it to work. While much of the Berkeley DB database format is architecture-independent, other aspects of the environment are not. Second, Subversion uses Berkeley DB in a way that will not operate on Windows 95/98 systems—if you need to house a BDB-backed repository on a Windows machine, stick with Windows 2000 or later.
While Berkeley DB promises to behave correctly on network shares that meet a particular set of specifications, [30] most networked filesystem types and appliances do not actually meet those requirements. And in no case can you allow a BDB-backed repository that resides on a network share to be accessed by multiple clients of that share at once (which quite often is the whole point of having the repository live on a network share in the first place).
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 fonctionnera. 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 [30], 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 sera 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).
WARNING
- If you attempt to use Berkeley DB on a noncompliant remote filesystem, the results are unpredictable—you may see mysterious errors right away, or it may be months before you discover that your repository database is subtly corrupted. You should strongly consider using the FSFS data store for repositories that need to live on a network share.
- 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.
Finally, because Berkeley DB is a library linked directly into Subversion, it's more sensitive to interruptions than a typical relational database system. Most SQL systems, for example, have a dedicated server process that mediates all access to tables. If a program accessing the database crashes for some reason, the database daemon notices the lost connection and cleans up any mess left behind. And because the database daemon is the only process accessing the tables, applications don't need to worry about permission conflicts. These things are not the case with Berkeley DB, however. Subversion (and programs using Subversion libraries) access the database tables directly, which means that a program crash can leave the database in a temporarily inconsistent, inaccessible state. When this happens, an administrator needs to ask Berkeley DB to restore to a checkpoint, which is a bit of an annoyance. Other things can cause a repository to “wedge” besides crashed processes, such as programs conflicting over ownership and permissions on the database files.
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.
POINT OF INTEREST
- Berkeley DB 4.4 brings (to Subversion 1.4 and later) the ability for Subversion to automatically and transparently recover Berkeley DB environments in need of such recovery. When a Subversion process attaches to a repository's Berkeley DB environment, it uses some process accounting mechanisms to detect any unclean disconnections by previous processes, performs any necessary recovery, and then continues on as though nothing happened. This doesn't completely eliminate instances of repository wedging, but it does drastically reduce the amount of human interaction required to recover from them.
- 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 tout problème éventuel de déconnexion antérieur, 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 interactions humaines nécessaires pour revenir à une situation normale sont considérablement réduites.
So while a Berkeley DB repository is quite fast and scalable, it's best used by a single server process running as one user—such as Apache's httpd or svnserve (see Chapter 6, Server Configuration)—rather than accessing it as many different users via file:// or svn+ssh:// URLs. If you're accessing a Berkeley DB repository directly as multiple users, be sure to read the section called “Supporting Multiple Repository Access Methods” later in this chapter.
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 le serveur Apache httpd ou svnserve - voir le chapitre 6, "Configuration du serveur") plutôt qu'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 "Support de plusieurs méthodes d'accès au dépôt" plus loin dans ce chapitre.
FSFS
In mid-2004, a second type of repository storage system—one that doesn't use a database at all—came into being. An FSFS repository stores the changes associated with a revision in a single file, and so all of a repository's revisions can be found in a single subdirectory full of numbered files. Transactions are created in separate subdirectories as individual files. When complete, the transaction file is renamed and moved into the revisions directory, thus guaranteeing that commits are atomic. And because a revision file is permanent and unchanging, the repository also can be backed up while “hot,” just like a BDB-backed repository.
The FSFS revision files describe a revision's directory structure, file contents, and deltas against files in other revision trees. Unlike a Berkeley DB database, this storage format is portable across different operating systems and isn't sensitive to CPU architecture. Because no journaling or shared-memory files are being used, the repository can be safely accessed over a network filesystem and examined in a read-only environment. The lack of database overhead also means the overall repository size is a bit smaller.
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 pour 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.
FSFS has different performance characteristics, too. When committing a directory with a huge number of files, FSFS is able to more quickly append directory entries. On the other hand, FSFS writes the latest version of a file as a delta against an earlier version, which means that checking out the latest tree is a bit slower than fetching the full-texts stored in a Berkeley DB HEAD revision. FSFS also has a longer delay when finalizing a commit, which could in extreme cases cause clients to time out while waiting for a response.
The most important distinction, however, is FSFS's imperviousness to wedging when something goes wrong. If a process using a Berkeley DB database runs into a permissions problem or suddenly crashes, the database can be left in an unusable state until an administrator recovers it. If the same scenarios happen to a process using an FSFS repository, the repository isn't affected at all. At worst, some transaction data is left behind.
The only real argument against FSFS is its relative immaturity compared to Berkeley DB. Unlike Berkeley DB, which has years of history, its own dedicated development team, and, now, Oracle's mighty name attached to it, [31] FSFS is a newer bit of engineering. Prior to Subversion 1.4, it was still shaking out some pretty serious data integrity bugs, which, while triggered in only very rare cases, nonetheless did occur. That said, FSFS has quickly become the backend of choice for some of the largest public and private Subversion repositories, and it promises a lower barrier to entry for Subversion across the board.
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 sera 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 [31]. FSFS est d'une 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.
