SVNBOOK Chap5 Creating and Configuring Your Repository
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 |
Titre
Earlier in this chapter (in the section called “Strategies for Repository Deployment”), we looked at some of the important decisions that should be made before creating and configuring your Subversion repository. Now, we finally get to get our hands dirty! In this section, we'll see how to actually create a Subversion repository and configure it to perform custom actions when special repository events occur.
Dans ce chapitre (dans la section "Stratégies de déploiement d'un dépôt"), nous avons passé en revue quelques décisions importantes à prendre avant de créer et de configurer votre dépôt Subversion. Maintenant, nous allons enfin mettre les mains dans le cambouis ! Dans cette section, nous allons voir comment créer un dépôt Subversion et le configurer pour qu'il effectue des actions personnalisées lorsque certains événements ont lieu.
Sous-Titre1
Subversion repository creation is an incredibly simple task. The svnadmin utility that comes with Subversion provides a subcommand (svnadmin create) for doing just that.
$ # Create a repository $ svnadmin create /var/svn/repos $
La création d'un dépôt Subversion est une tâche incroyablement simple. L'utilitaire svnadmin, fourni avec Subversion, propose une sous-commande qui est justement destinée à cela - svnadmin create :
$ # Créer un dépôt $ svnadmin create /var/svn/depot $
This creates a new repository in the directory /var/svn/repos, and with the default filesystem data store. Prior to Subversion 1.2, the default was to use Berkeley DB; the default is now FSFS. You can explicitly choose the filesystem type using the --fs-type argument, which accepts as a parameter either fsfs or bdb.
$ # Create an FSFS-backed repository $ svnadmin create --fs-type fsfs /var/svn/repos $ # Create a Berkeley-DB-backed repository $ svnadmin create --fs-type bdb /var/svn/repos $
After running this simple command, you have a Subversion repository.
Cette commande crée un dépôt dans le répertoire /var/svn/depot avec le magasin de données par défaut. Avant la version 1.2 de Subversion, le choix par défaut était l'utilisation d'une base de données Berkeley DB ; maintenant, c'est FSFS. Vous pouvez choisir explicitement le type de système de fichiers avec l'option --fs-type qui accepte comme argument soit fsfs, soit bdb.
$ # Créer un dépôt FSFS $ svnadmin create --fs-type fsfs /var/svn/depot $ $ # Créer un dépôt Berkeley DB $ svnadmin create --fs-type bdb /var/svn/depot $
Après l'exécution de cette simple commande, vous disposez d'un dépôt Subversion.
TIP
- The path argument to svnadmin is just a regular filesystem path and not a URL like the svn client program uses when referring to repositories. Both svnadmin and svnlook are considered server-side utilities—they are used on the machine where the repository resides to examine or modify aspects of the repository, and are in fact unable to perform tasks across a network. A common mistake made by Subversion newcomers is trying to pass URLs (even “local” file:// ones) to these two programs.
- Le chemin en argument de svnadmin est juste un chemin classique du système de fichiers, pas une URL comme celles que svn client utilise pour spécifier un dépôt. svnadmin et svnlook sont toutes les deux considérées comme des utilitaires coté serveur : elles sont utilisées sur la machine qui héberge le dépôt pour examiner ou modifier certains aspects du dépôt et ne sont pas capables d'effectuer des actions via le réseau. Une erreur classique des nouveaux utilisateurs de Subversion est d'essayer de passer une URL (même locale comme file://) à ces deux programmes.
Present in the db/ subdirectory of your repository is the implementation of the versioned filesystem. Your new repository's versioned filesystem begins life at revision 0, which is defined to consist of nothing but the top-level root (/) directory. Initially, revision 0 also has a single revision property, svn:date, set to the time at which the repository was created.
Now that you have a repository, it's time to customize it.
Dans le sous-répertoire db/ de votre dépôt, vous trouverez l'implémentation du système de fichiers suivi en versions. Le nouveau système de fichiers suivi en versions de votre dépôt commence sa vie à la révision 0, qui est définie comme contenant le répertoire racine (/) et lui seul. Initialement, la révision 0 possède une seule propriété de révision, svn:date, dont la valeur est la date de création du dépôt.
Maintenant que vous disposez d'un dépôt, il est temps de le personnaliser.
WARNING
- While some parts of a Subversion repository—such as the configuration files and hook scripts—are meant to be examined and modified manually, you shouldn't (and shouldn't need to) tamper with the other parts of the repository “by hand.” The svnadmin tool should be sufficient for any changes necessary to your repository, or you can look to third-party tools (such as Berkeley DB's tool suite) for tweaking relevant subsections of the repository. Do not attempt manual manipulation of your version control history by poking and prodding around in your repository's data store files!
- Alors que certaines parties d'un dépôt Subversion sont conçues pour être examinées et modifiées à la main (comme les fichiers de configuration et les procédures automatiques), vous ne devriez pas (et vous ne devriez pas avoir besoin de) modifier les autres parties "à la main". L'outil svnadmin est censé être suffisant pour toutes les modifications à apporter à votre dépôt, ou alors vous pouvez regarder du côté d'outils tiers (comme la suite d'outils Berkeley DB) pour configurer les parties adéquates du dépôt. Ne tentez surtout pas de manipuler manuellement l'historique du suivi de versions à petits coups par-ci par-là dans les fichiers du magasin de données du dépôt !
Sous-Titre2
Mettre en place des procédures automatiques
A hook is a program triggered by some repository event, such as the creation of a new revision or the modification of an unversioned property. Some hooks (the so-called “pre hooks”) run in advance of a repository operation and provide a means by which to both report what is about to happen and prevent it from happening at all. Other hooks (the “post hooks”) run after the completion of a repository event and are useful for performing tasks that examine—but don't modify—the repository. Each hook is handed enough information to tell what that event is (or was), the specific repository changes proposed (or completed), and the username of the person who triggered the event.
Une procédure automatique (hook en anglais) est un programme activé par certains événements du dépôt, comme la création d'une nouvelle révision ou la modification d'une propriété non suivie en versions. Certaines procédures automatiques (appelées "pré hooks") sont déclenchées avant l'opération sur le dépôt et permettent à la fois de rendre compte de ce qui va se passer et d'empêcher que cela se passe. D'autres procédures automatiques (appelées "post hooks") sont déclenchées après la fin d'un événement et servent à effectuer des tâches de surveillance (mais pas de modification) du dépôt. Chaque procédure automatique reçoit suffisamment d'informations pour déterminer la nature de l'événement, les modifications proposées (ou effectuées) du dépôt et le nom d'utilisateur de la personne qui a déclenché l'événement.
The hooks subdirectory is, by default, filled with templates for various repository hooks:
$ ls repos/hooks/ post-commit.tmpl post-unlock.tmpl pre-revprop-change.tmpl post-lock.tmpl pre-commit.tmpl pre-unlock.tmpl post-revprop-change.tmpl pre-lock.tmpl start-commit.tmpl $
Le sous-répertoire hooks contient, par défaut, des modèles pour diverses procédures automatiques :
$ ls depot/hooks/ post-commit.tmpl post-unlock.tmpl pre-revprop-change.tmpl post-lock.tmpl pre-commit.tmpl pre-unlock.tmpl post-revprop-change.tmpl pre-lock.tmpl start-commit.tmpl $
There is one template for each hook that the Subversion repository supports; by examining the contents of those template scripts, you can see what triggers each script to run and what data is passed to that script. Also present in many of these templates are examples of how one might use that script, in conjunction with other Subversion-supplied programs, to perform common useful tasks. To actually install a working hook, you need only place some executable program or script into the repos/hooks directory, which can be executed as the name (such as start-commit or post-commit) of the hook.
Il y a un modèle pour chaque type de procédure automatique que le dépôt Subversion sait prendre en charge ; en examinant le contenu de ces modèles de scripts, vous pourrez voir ce qui déclenche le script et quelles données sont passées en paramètres. Vous trouverez également dans beaucoup de ces scripts des exemples d'utilisation permettant de réaliser des tâches récurrentes utiles, en conjonction avec d'autres programmes fournis avec Subversion. Concrètement, pour activer une procédure automatique, il suffit de placer dans le répertoire depot/hooks un programme ou un script exécutable, qui sera invoqué via le nom de la procédure automatique (comme start-commit pour le début d'une propagation ou post-commit pour la fin d'une propagation).
On Unix platforms, this means supplying a script or program (which could be a shell script, a Python program, a compiled C binary, or any number of other things) named exactly like the name of the hook. Of course, the template files are present for more than just informational purposes—the easiest way to install a hook on Unix platforms is to simply copy the appropriate template file to a new file that lacks the .tmpl extension, customize the hook's contents, and ensure that the script is executable. Windows, however, uses file extensions to determine whether a program is executable, so you would need to supply a program whose basename is the name of the hook and whose extension is one of the special extensions recognized by Windows for executable programs, such as .exe for programs and .bat for batch files.
Sur les plates-formes Unix, cela veut dire fournir un programme ou un script (pouvant être un script shell, un programme Python, l'exécutable binaire d'un programme en C ou tout un tas d'autres choses) dont le nom est exactement le nom de la procédure automatique. Bien sûr, les modèles qui sont fournis ne le sont pas juste à titre d'information. Le moyen le plus facile pour mettre en place une procédure automatique sur les plates-formes Unix consiste tout simplement à copier le fichier du modèle adéquat vers un nouveau fichier qui n'aura pas l'extension .tmpl, d'adapter son contenu à votre environnement et de vous assurer qu'il est exécutable. Sous Windows, comme l'extension du fichier détermine s'il est exécutable ou non, vous devrez fournir un programme dont la base du nom est le nom de la procédure automatique et dont l'extension sera une de celles reconnue comme exécutable par Windows, comme .exe pour les programmes ou .bat pour les fichiers batch.
TIP
- For security reasons, the Subversion repository executes hook programs with an empty environment—that is, no environment variables are set at all, not even $PATH (or %PATH%, under Windows). Because of this, many administrators are baffled when their hook program runs fine by hand, but doesn't work when run by Subversion. Be sure to explicitly set any necessary environment variables in your hook program and/or use absolute paths to programs.
- Pour des raisons de sécurité, le dépôt Subversion exécute les procédures automatiques avec un environnement vide - c'est-à-dire sans aucune variable d'environnement définie, même pas $PATH (ou %PATH% sous Windows). C'est ainsi que de nombreux administrateurs sont perplexes lorsque leurs programmes fonctionnent correctement à la main mais pas dans Subversion. Assurez-vous de définir explicitement toutes les variables d'environnement nécessaires dans votre procédure automatique et/ou d'utiliser des chemins absolus vers les programmes.
Subversion executes hooks as the same user who owns the process that is accessing the Subversion repository. In most cases, the repository is being accessed via a Subversion server, so this user is the same user as whom the server runs on the system. The hooks themselves will need to be configured with OS-level permissions that allow that user to execute them. Also, this means that any programs or files (including the Subversion repository) accessed directly or indirectly by the hook will be accessed as the same user. In other words, be alert to potential permission-related problems that could prevent the hook from performing the tasks it is designed to perform.
Les procédures automatiques de Subversion sont lancées par l'utilisateur propriétaire du processus ayant accès au dépôt Subversion. La plupart du temps, on accède au dépôt via un serveur Subversion, donc cet utilisateur est le même que celui qui fait tourner le processus serveur sur le système. Les procédures automatiques elles-mêmes devront être configurées pour être exécutables, au niveau de l'OS, par ledit utilisateur. Cela implique également que tout programme ou fichier (y compris le dépôt Subversion) utilisé directement ou indirectement par la procédure automatique le sera par ledit utilisateur. En d'autres termes, faites bien attention aux problèmes de droits d'exécution qui pourraient empêcher les scripts d'effectuer correctement les tâches pour lesquelles ils ont été conçus.
There are serveral hooks implemented by the Subversion repository, and you can get details about each of them in the section called “Repository Hooks”. As a repository administrator, you'll need to decide which hooks you wish to implement (by way of providing an appropriately named and permissioned hook program), and how. When you make this decision, keep in mind the big picture of how your repository is deployed. For example, if you are using server configuration to determine which users are permitted to commit changes to your repository, you don't need to do this sort of access control via the hook system.
Il y a plusieurs procédures automatiques implémentées dans le dépôt Subversion et vous pouvez obtenir des détails sur chacune d'elles dans la section "Procédures automatiques du dépôt". En tant qu'administrateur du dépôt, vous devrez décider quelles procédures automatiques vous voulez mettre en oeuvre (c'est-à-dire les nommer correctement et leur donner les droits appropriés), et de quelle manière. Lorsque vous prendrez cette décision, gardez à l'esprit l'architecture de votre dépôt. Par exemple, si vous vous servez de la configuration du serveur pour déterminer les droits de propagation sur votre dépôt, vous n'avez pas besoin de mettre en place un contrôle d'accès de ce style via les procédures automatiques.
There is no shortage of Subversion hook programs and scripts that are freely available either from the Subversion community itself or elsewhere. These scripts cover a wide range of utility—basic access control, policy adherence checking, issue tracker integration, email- or syndication-based commit notification, and beyond. Or, if you wish to write your own, see Chapter 8, Embedding Subversion.
Les exemples de procédures automatiques librement accessibles sont légions, fournis par la communauté Subversion elle-même ou par d'autres. Ces scripts couvrent une large variété de besoins tels que le contrôle d'accès basique, le contrôle de cohérence, l'intégration avec les outils de suivis de bogues, les notifications de propagation par e-mail ou flux RSS, etc. Ou, si vous voulez écrire votre propre programme, penchez-vous sur le chapitre 8, "Embarquer Subversion".
WARNING
- While hook scripts can do almost anything, there is one dimension in which hook script authors should show restraint: do not modify a commit transaction using hook scripts. While it might be tempting to use hook scripts to automatically correct errors, shortcomings, or policy violations present in the files being committed, doing so can cause problems. Subversion keeps client-side caches of certain bits of repository data, and if you change a commit transaction in this way, those caches become indetectably stale. This inconsistency can lead to surprising and unexpected behavior. Instead of modifying the transaction, you should simply validate the transaction in the pre-commit hook and reject the commit if it does not meet the desired requirements. As a bonus, your users will learn the value of careful, compliance-minded work habits.
- Bien que les procédures automatiques soient capables de faire tout et n'importe quoi, leurs auteurs devraient faire preuve de modération dans un domaine précis : ne modifiez pas une transaction de propagation en utilisant une procédure automatique. Bien que cela soit tentant de corriger automatiquement certaines erreurs, raccourcis ou violations de politique constatées dans les fichiers propagés, cela peut causer des problèmes. Subversion conserve en cache, côté client, certaines parties des données du dépôt et si vous modifiez une transaction de propagation de cette façon, ces caches en seront périmés sans que cela ne puisse être détecté. De telles incohérences peuvent aboutir à des comportements surprenants et inattendus. Au lieu de modifier la transaction, contentez-vous de vérifier la transaction dans la procédure automatique préalable à la propagation et rejetez-la si elle ne remplit pas les conditions nécessaires. Entre autre avantages, vos utilisateurs prendront ainsi des habitudes de travail empreintes de respect des procédures et de qualité.
Sous-titre 3
A Berkeley DB environment is an encapsulation of one or more databases, logfiles, region files, and configuration files. The Berkeley DB environment has its own set of default configuration values for things such as the number of database locks allowed to be taken out at any given time, the maximum size of the journaling logfiles, and so on. Subversion's filesystem logic additionally chooses default values for some of the Berkeley DB configuration options. However, sometimes your particular repository, with its unique collection of data and access patterns, might require a different set of configuration option values.
Un environnement Berkeley DB peut encapsuler une ou plusieurs bases de données, fichiers de journalisation, de région et de configuration. L'environnement Berkeley DB a un ensemble propre de valeurs configurées par défaut comme par exemple le nombre de verrous autorisés à un instant donné, la taille maximum des fichiers de journalisation, etc. La logique du système de fichiers Subversion ajoute des valeurs par défaut pour différentes options de configuration du gestionnaire Berkeley DB. Cependant, il se peut que votre dépôt nécessite une configuration différente en raison de l'architecture de vos données et des méthodes d'accès.
Les concepteurs du gestionnaire de bases de données Berkeley DB comprennent que les besoins varient entre les différentes applications et environnements de bases de données, c'est pourquoi ils fournissent des mécanismes pour modifier, à l'exécution, une grande partie des valeurs des options de configuration. BDB vérifie la présence d'un fichier nommé DB_CONFIG dans le répertoire d'environnement (à savoir le sous-répertoire db du dépôt) et en extrait les valeurs des options. Subversion crée ce fichier lorsqu'il crée le reste du dépôt. Le fichier contient initialement des options par défaut ainsi que des pointeurs vers la documentation en ligne de Berkeley DB afin de vous renseigner sur l'utilisation de ces options. Bien sûr, vous êtes libre d'ajouter n'importe quelle option prise en compte par Berkeley DB dans votre fichier DB_CONFIG. Soyez juste attentif au fait que, bien que Subversion n'essaie jamais de lire ou interpréter le contenu de ce fichier et qu'il n'en utilise pas directement la configuration, les changements induits dans le comportement de Berkeley DB ne doivent pas aller à l'encontre du comportement attendu par Subversion. Par ailleurs, les changements effectués dans DB_CONFIG ne seront pris en considération qu'après avoir effectué une restauration de l'environnement de la base de données avec la commande svnadmin recover.
