[svnbook] r3692 committed - Translation to French of chapter 5 : in progress.
svnbook at googlecode.com
svnbook at googlecode.com
Fri Feb 12 13:56:20 CST 2010
Revision: 3692
Author: christophe.nanteuil
Date: Fri Feb 12 11:56:04 2010
Log: Translation to French of chapter 5 : in progress.
http://code.google.com/p/svnbook/source/detail?r=3692
Modified:
/trunk/src/fr/book/ch05-repository-admin.xml
=======================================
--- /trunk/src/fr/book/ch05-repository-admin.xml Fri Sep 12 07:39:35 2008
+++ /trunk/src/fr/book/ch05-repository-admin.xml Fri Feb 12 11:56:04 2010
@@ -1,136 +1,139 @@
<chapter id="svn.reposadmin">
- <title>Repository Administration</title>
-
- <para>The Subversion repository is the central storehouse of all
- your versioned data. As such, it becomes an obvious candidate for
- all the love and attention an administrator can offer. While the
- repository is generally a low-maintenance item, it is important to
- understand how to properly configure and care for it so that
- potential problems are avoided, and so actual problems are safely
- resolved.</para>
-
- <para>In this chapter, we'll discuss how to create and configure a
- Subversion repository. We'll also talk about repository
- maintenance, providing examples of how and when to use the
- <command>svnlook</command> and <command>svnadmin</command> tools
- provided with Subversion. We'll address some common questions and
- mistakes and give some suggestions on how to arrange the data in
- the repository.</para>
-
- <para>If you plan to access a Subversion repository only in the
- role of a user whose data is under version control (i.e., via
- a Subversion client), you can skip this chapter altogether.
- However, if you are, or wish to become, a Subversion repository
- administrator,
+ <title>Administration d'un dépôt</title>
+
+ <para>Le dépôt Subversion est le centre de stockage de toutes vos
+ données suivies en versions. Ainsi, il est de facto l'objet de toute
+ l'attention et de tous les soins de l'administrateur. Bien que ce
+ soit un élément ne nécessitant pas énormément de maintenance, il est
+ important de comprendre comment le configurer et le surveiller
+ correctement de manière à éviter d'éventuels problèmes et à résoudre
+ proprement ceux qui se présentent.</para>
+
+ <para>Dans ce chapitre, nous verrons comment créer et configurer un
+ dépôt Subversion. Nous aborderons également la maintenance du dépôt,
+ en donnant des exemples d'utilisation des outils
+ <command>svnlook</command> et <command>svnadmin</command> fournis
+ avec Subversion. Nous étudierons quelques questions et erreurs
+ communes et nous donnerons des conseils sur l'organisation des
+ données dans le dépôt.</para>
+
+ <para>Si vous n'envisagez pas d'utiliser un dépôt Subversion autrement
+ qu'en simple utilisateur des données (c'est-à-dire en utilisant un
+ client Subversion), vous pouvez sauter ce chapitre. Cependant, si
+ vous êtes (ou si vous êtes appelé à être) l'administrateur d'un
+ dépôt
<footnote>
- <para>This may sound really prestigious and lofty, but we're
- just talking about anyone who is interested in that
- mysterious realm beyond the working copy where everyone's
- data hangs out.</para>
- </footnote>
- this chapter is for you.</para>
+ <para>Cela peut sembler prestigieux et noble, mais il s'agit juste
+ en fait d'une personne intéressée par le monde mystérieux qui se
+ cache derrière la copie de travail que chacun détient.</para>
+ </footnote>, ce chapitre est fait pour vous.</para>
<!-- =================================================================
-->
<!-- =================================================================
-->
<!-- =================================================================
-->
<sect1 id="svn.reposadmin.basics">
- <title>The Subversion Repository, Defined</title>
-
- <para>Before jumping into the broader topic of repository
- administration, let's further define what a repository is. How
- does it look? How does it feel? Does it take its tea hot or
- iced, sweetened, and with lemon? As an administrator, you'll be
- expected to understand the composition of a repository both from
- a literal, OS-level perspective—how a repository looks and
- acts with respect to non-Subversion tools—and from a
- logical perspective—dealing with how data is represented
- <emphasis>inside</emphasis> the repository.</para>
-
- <para>Seen through the eyes of a typical file browser application
- (such as Windows Explorer) or command-line based filesystem
- navigation tools, the Subversion repository is just another
- directory full of stuff. There are some subdirectories with
- human-readable configuration files in them, some subdirectories
- with some not-so-human-readable data files, and so on. As in
- other areas of the Subversion design, modularity is given high
- regard, and hierarchical organization is preferred to cluttered
- chaos. So a shallow glance into a typical repository from a
- nuts-and-bolts perspective is sufficient to reveal the basic
- components of the repository:</para>
+ <title>Définition d'un dépôt Subversion</title>
+
+ <para>Avant d'aborder le vaste sujet de l'administration d'un dépôt,
+ définissons plus précisément ce qu'est un dépôt. A quoi
+ ressemble-t-il ? Que ressent-il ? Est-ce qu'il préfère son
+ thé chaud ou glacé, sucré, avec une tranche de citron ? En
+ tant qu'administrateur, vous vous devez de comprendre de quoi est
+ composé un dépôt, à la fois au niveau du système d'exploitation
+ (à quoi ressemble le dépôt et comment il réagit vis-à-vis des
+ outils autres que Subversion) et au niveau logique de
+ l'organisation des données (comment elles sont représentées
+ <emphasis>à l'intérieur</emphasis> du dépôt.</para>
+
+ <para>Du point de vue d'un explorateur de fichiers classique (comme
+ Windows Explorer) ou d'un outil de navigation du système de
+ fichiers en ligne de commande, un dépôt Subversion n'est rien
+ d'autre qu'un répertoire contenant plein de choses. Il y a des
+ sous-répertoires avec des fichiers de configuration lisibles par
+ un humain, des sous-répertoires avec des fichiers de données
+ binaires déjà bien moins lisibles, etc. A l'instar d'autres
+ parties de Subversion, la modularité est une préoccupation majeure
+ et l'organisation hiérarchique prévaut sur le bazar. Un coup
+ d'oeil rapide dans un dépôt typique est suffisant pour obtenir la
+ liste des composants essentiels d'un dépôt :</para>
<screen>
-$ ls repos
+$ ls depot
conf/ dav/ db/ format hooks/ locks/ README.txt
</screen>
- <para>Here's a quick fly-by overview of what exactly you're seeing
- in this directory listing. (Don't get bogged down in the
- terminology—detailed coverage of these components exists
- elsewhere in this and other chapters.)</para>
+ <para>Effectuons un survol rapide de ce que nous voyons dans ce
+ répertoire (ne vous inquiétez pas si vous ne comprenez pas tous
+ les termes employés, ils sont expliqués dans ce chapitre ou
+ ailleurs dans ce livre) :</para>
<variablelist>
<varlistentry>
<term>conf</term>
<listitem>
- <para>A directory containing configuration files</para>
+ <para>un répertoire contenant des fichiers de
+ configuration</para>
</listitem>
</varlistentry>
<varlistentry>
<term>dav</term>
<listitem>
- <para>A directory provided to
- <filename>mod_dav_svn</filename> for its private
- housekeeping data</para>
+ <para>un répertoire à disposition de
+ <filename>mod_dav_svn</filename> pour y stocker ses
+ informations privées </para>
</listitem>
</varlistentry>
<varlistentry>
<term>db</term>
<listitem>
- <para>The data store for all of your versioned data</para>
+ <para>le magasin de données pour toutes vos données suivies en
+ versions</para>
</listitem>
</varlistentry>
<varlistentry>
<term>format</term>
<listitem>
- <para>A file that contains a single integer that
- indicates the version number of the repository layout</para>
+ <para>un fichier contenant un unique entier qui indique le
+ numéro de version de l'organisation du dépôt</para>
</listitem>
</varlistentry>
<varlistentry>
<term>hooks</term>
<listitem>
- <para>A directory full of hook script templates (and hook
- scripts themselves, once you've installed some)</para>
+ <para>un répertoire plein de modèles de procédures
+ automatiques (et les procédures automatiques elles-mêmes,
+ une fois installées)</para>
</listitem>
</varlistentry>
<varlistentry>
<term>locks</term>
<listitem>
- <para>A directory for Subversion's repository lock
- files, used for tracking accessors to the repository</para>
+ <para>un répertoire pour les fichiers de verrous du dépôt
+ Subversion, utilisé pour garder trace de qui accède au
+ dépôt </para>
</listitem>
</varlistentry>
<varlistentry>
<term>README.txt</term>
<listitem>
- <para>A file whose contents merely inform its readers that
- they are looking at a Subversion repository</para>
+ <para>un fichier qui ne fait qu'informer son lecteur qu'il est
+ tombé sur un dépôt Subversion</para>
</listitem>
</varlistentry>
</variablelist>
- <para>Of course, when accessed via the Subversion libraries, this
- otherwise unremarkable collection of files and directories
- suddenly becomes an implementation of a virtual, versioned
- filesystem, complete with customizable event triggers. This
- filesystem has its own notions of directories and files, very
- similar to the notions of such things held by real filesystems
- (such as NTFS, FAT32, ext3, etc.). But this is a special
- filesystem—it hangs these directories and files from
- revisions, keeping all the changes you've ever made to them
- safely stored and forever accessible. This is where the
- entirety of your versioned data lives.</para>
+ <para>Bien sûr, quand on y accède via les bibliothèques Subversion,
+ cet ensemble de fichiers et de répertoires se transforme en un
+ système virtuel de fichiers suivis en versions, complet et
+ comportant une gestion des événements personnalisable. Ce système
+ de fichiers possède ses propres notions de répertoires et de
+ fichiers, très similaires aux notions des systèmes de fichiers
+ réels (tels que NTFS, FAT32, ext3, etc.). Mais c'est un système de
+ fichiers spécial : il base ces répertoires et ces fichiers
+ sur les révisions, gardant une trace des tous les changements
+ effectués de manière sûre et accessible pour toujours. C'est là
+ que la totalité de vos données suivies en versions réside.</para>
</sect1>
@@ -138,89 +141,88 @@
<!-- =================================================================
-->
<!-- =================================================================
-->
<sect1 id="svn.reposadmin.planning">
- <title>Strategies for Repository Deployment</title>
-
- <para>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.</para>
-
- <para>Some things you'll want to consider beforehand, though,
are:</para>
+ <title>Stratégies de déploiement d'un dépôt</title>
+
+ <para>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.</para>
+
+ <para>Voici quelques questions à se poser avant toute
chose :</para>
<itemizedlist>
<listitem>
- <para>What data do you expect to live in your repository (or
- repositories), and how will that data be organized?</para>
+ <para>Quelles données vont être hébergées dans le dépôt (ou les
+ dépôts) et quelle en sera l'organisation ?</para>
</listitem>
<listitem>
- <para>Where will your repository live, and how will it be
- accessed?</para>
+ <para>Où sera placé le dépôt et comment les utilisateurs y
+ accéderont-ils ?</para>
</listitem>
<listitem>
- <para>What types of access control and repository event
- reporting do you need?</para>
+ <para>De quels types de contrôle d'accès et de notifications
+ d'événements avez-vous besoin ?</para>
</listitem>
<listitem>
- <para>Which of the available types of data store do you want
- to use?</para>
+ <para>Quel type de magasin de données désirez-vous
+ utiliser ?</para>
</listitem>
</itemizedlist>
- <para>In this section, we'll try to help you answer those
- questions.</para>
+ <para>Dans cette section, nous allons essayer de vous aider à
+ répondre à ces questions.</para>
<!-- ===============================================================
-->
<sect2 id="svn.reposadmin.projects.chooselayout">
- <title>Planning Your Repository Organization</title>
-
- <para>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 <quote>laying out</quote> your repository or
- repositories and their versioned contents ahead of time, you
- can prevent many future headaches.</para>
-
- <para>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.</para>
-
- <para>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.</para>
-
- <para>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.
+ <title>Prévoir l'organisation de votre dépôt</title>
+
+ <para>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 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.</para>
+
+ <para>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.</para>
+
+ <para>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.</para>
+
+ <para>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
+ 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.
<footnote>
<para>Whether founded in ignorance or in poorly considered
concepts about how to derive legitimate software
@@ -231,442 +233,469 @@
</footnote>
</para>
- <para>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.</para>
-
- <para>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 <xref linkend="svn.branchmerge"/>), the
- Subversion community recommends that you choose a repository
- location for each <firstterm>project
- root</firstterm>—the <quote>topmost</quote> directory
- that contains data related to that project—and then
- create three subdirectories beneath that root:
- <filename>trunk</filename>, meaning the directory under which
- the main project development occurs;
- <filename>branches</filename>, which is a directory in which
- to create various named branches of the main development line;
- and <filename>tags</filename>, which is a collection of tree
- snapshots that are created, and perhaps destroyed, but never
- changed.
+ <para>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.</para>
+
+ <para>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
+ <xref linkend="svn.branchmerge"/>), la communauté Subversion
+ recommande de choisir un endroit dans le dépôt pour la
+ <firstterm>racine</firstterm> 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 :
+ <filename>trunk</filename> (tronc en français), le répertoire
+ qui héberge les principaux développements du projet ;
+ <filename>branches</filename>, le répertoire dans lequel seront
+ créées les différentes variations de la ligne de développement
+ principale ; et <filename>tags</filename>, (é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)
<footnote>
- <para>The <filename>trunk</filename>, <filename>tags</filename>,
+ <para>Le trio <filename>trunk</filename>,
<filename>tags</filename>,
and <filename>branches</filename> trio is sometimes referred
to as <quote>the TTB directories.</quote></para>
- </footnote>
+ </footnote>.
</para>
- <para>For example, your repository might look like this:</para>
+ <para>Par exemple, votre dépôt pourrait ressembler à
+ ceci :</para>
<screen>
-/
- calc/
- trunk/
- tags/
- branches/
- calendar/
- trunk/
- tags/
- branches/
- spreadsheet/
- trunk/
- tags/
- branches/
+ /
+ calculatrice/
+ trunk/
+ tags/
+ branches/
+ calendrier/
+ trunk/
+ tags/
+ branches/
+ tableur/
+ trunk/
+ tags/
+ branches/
…
</screen>
- <para>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:</para>
+ <para>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 :</para>
<screen>
-/
- utils/
- calc/
- trunk/
- tags/
- branches/
- calendar/
- trunk/
- tags/
- branches/
+ /
+ utilitaires/
+ calculatrice/
+ trunk/
+ tags/
+ branches/
+ calendrier/
+ trunk/
+ tags/
+ branches/
…
- office/
- spreadsheet/
- trunk/
- tags/
- branches/
+ bureautique/
+ tableur/
+ trunk/
+ tags/
+ branches/
…
</screen>
- <para>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.</para>
-
- <para>In the name of full disclosure, though, we'll mention
- another very common layout. In this layout, the
- <filename>trunk</filename>, <filename>tags</filename>, and
- <filename>branches</filename> directories live in the root
- directory of your repository, and your projects are in
- subdirectories beneath those, like so:</para>
+ <para>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.</para>
+
+ <para>Cependant, par souci de transparence, nous signalerons une
+ autre organisation également très répandue. Dans cette
+ organisation, les répertoires <filename>trunk</filename>,
+ <filename>tags</filename>, et <filename>branches</filename> 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 :</para>
<screen>
-/
- trunk/
- calc/
- calendar/
- spreadsheet/
+ /
+ trunk/
+ calculatrice/
+ calendrier/
+ tableur/
…
- tags/
- calc/
- calendar/
- spreadsheet/
+ tags/
+ calculatrice/
+ calendrier/
+ tableur/
…
- branches/
- calc/
- calendar/
- spreadsheet/
+ branches/
+ calculatrice/
+ calendrier/
+ tableur/
…
</screen>
- <para>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.</para>
+ <para>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
+ <quote>plusieurs projets par branche</quote> 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.</para>
</sect2>
<!-- ===============================================================
-->
<sect2 id="svn.reposadmin.basics.hosting">
- <title>Deciding Where and How to Host Your Repository</title>
-
- <para>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.</para>
-
- <para>We cover server choice and configuration in <xref
- linkend="svn.serverconfig" />, 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.</para>
-
- <para>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.</para>
+ <title>Décider où et comment héberger votre dépôt</title>
+
+ <para>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. </para>
+
+ <para>Le choix et la configuration du serveur seront abordés au
+ <xref linkend="svn.serverconfig" />, 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.</para>
+
+ <para>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.</para>
</sect2>
<!-- ===============================================================
-->
<sect2 id="svn.reposadmin.basics.backends">
- <title>Choosing a Data Store</title>
-
- <para>As of version 1.1, Subversion provides two options for the
- type of underlying data store—often referred to as
- <quote>the backend</quote> or, somewhat confusingly,
- <quote>the (versioned) filesystem</quote>—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
- <quote>BDB-backed.</quote> 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 <firstterm>FSFS</firstterm>
+ <title>Choisir un magasin de données</title>
+
+ <para>Depuis la version 1.1, Subversion offre deux types de
+ stockage interne pour le magasin de données — souvent
+ désigné par <quote>backend</quote> en anglais (sans équivalent
+ en français) ou, ce qui peut être source de confusion, <quote>le
+ système de fichiers (versionné)</quote> — 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 <quote>dépôts
+ gérés par BDB</quote> ou <quote>dépôts BDB</quote>. 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
+ <firstterm>FSFS</firstterm>
<footnote>
<para>Often pronounced <quote>fuzz-fuzz,</quote> if Jack
Repenning has anything to say about it. (This book,
however, assumes that the reader is thinking
<quote>eff-ess-eff-ess.</quote>)</para>
</footnote>
- —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.</para>
-
- <para><xref linkend="svn.reposadmin.basics.backends.tbl-1" />
- gives a comparative overview of Berkeley DB and FSFS
- repositories.</para>
+ — 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.</para>
+
+ <para>Le <xref linkend="svn.reposadmin.basics.backends.tbl-1" />
+ offre une présentation comparée des dépôts utilisant Berkeley DB
+ et FSFS.</para>
<table id="svn.reposadmin.basics.backends.tbl-1">
- <title>Repository data store comparison</title>
+ <title>Comparaison des magasins de données de dépôts</title>
<tgroup cols="4">
<thead>
<row>
- <entry>Category</entry>
- <entry>Feature</entry>
+ <entry>Catégorie</entry>
+ <entry>Fonctionnalité</entry>
<entry>Berkeley DB</entry>
<entry>FSFS</entry>
</row>
</thead>
<tbody>
<row>
- <entry morerows="1">Reliability</entry>
- <entry>Data integrity</entry>
- <entry>When properly deployed, extremely reliable;
- Berkeley DB 4.4 brings auto-recovery</entry>
- <entry>Older versions had some rarely demonstrated, but
- data-destroying bugs</entry>
+ <entry morerows="1">Fiabilité</entry>
+ <entry>Intégrité des données</entry>
+ <entry>Très fiable quand déployé correctement ;
+ Berkeley DB 4.4 apporte l'auto-restauration</entry>
+ <entry>Les vieilles versions avaient quelques bogues
+ (rarement démontrés) qui détruisaient des
+ données</entry>
</row>
<row>
- <entry>Sensitivity to interruptions</entry>
- <entry>Very; crashes and permission problems can leave the
- database <quote>wedged,</quote> requiring journaled
- recovery procedures</entry>
- <entry>Quite insensitive</entry>
+ <entry>Sensibilité aux interruptions</entry>
+ <entry>Forte ; les <quote>plantages</quote> 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</entry>
+ <entry>Quasiment insensible</entry>
</row>
<row>
- <entry morerows="3">Accessibility</entry>
- <entry>Usable from a read-only mount</entry>
- <entry>No</entry>
- <entry>Yes</entry>
+ <entry morerows="3">Accessibilité</entry>
+ <entry>Utilisable depuis un montage en lecture seule</entry>
+ <entry>Non</entry>
+ <entry>Oui</entry>
</row>
<row>
- <entry>Platform-independent storage</entry>
- <entry>No</entry>
- <entry>Yes</entry>
+ <entry>Stockage indépendant de la plate-forme</entry>
+ <entry>Non</entry>
+ <entry>Oui</entry>
</row>
<row>
- <entry>Usable over network filesystems</entry>
- <entry>Generally, no</entry>
- <entry>Yes</entry>
+ <entry>Utilisable sur des systèmes de fichiers en
réseau</entry>
+ <entry>Généralement non</entry>
+ <entry>Oui</entry>
</row>
<row>
- <entry>Group permissions handling</entry>
- <entry>Sensitive to user umask problems; best if accessed
- by only one user</entry>
- <entry>Works around umask problems</entry>
+ <entry>Gestion des droits pour les groupes </entry>
+ <entry>Sensible aux problèmes de umask de
+ l'utilisateur ; c'est mieux si un seul utilisateur
+ y accède</entry>
+ <entry>Contourne les problèmes de umask</entry>
</row>
<row>
- <entry morerows="2">Scalability</entry>
- <entry>Repository disk usage</entry>
- <entry>Larger (especially if logfiles aren't purged)</entry>
- <entry>Smaller</entry>
+ <entry morerows="2">Extensibilité</entry>
+ <entry>Utilisation des disques sur le dépôt</entry>
+ <entry>Plus grande (surtout si les fichiers de
+ journalisation ne sont pas purgés) </entry>
+ <entry>Plus faible</entry>
</row>
<row>
- <entry>Number of revision trees</entry>
- <entry>Database; no problems</entry>
- <entry>Some older native filesystems don't scale well with
- thousands of entries in a single directory</entry>
+ <entry>Nombre de révisions</entry>
+ <entry>Base de données, pas de problème</entry>
+ <entry>De vieux systèmes de fichiers fonctionnent moins
+ bien lorsqu'il y a plusieurs milliers d'entrées dans un
+ seul répertoire</entry>
</row>
<row>
- <entry>Directories with many files</entry>
- <entry>Slower</entry>
- <entry>Faster</entry>
+ <entry> Répertoires avec beaucoup de fichiers</entry>
+ <entry>Plus lent</entry>
+ <entry>Plus rapide</entry>
</row>
<row>
- <entry morerows="1">Performance</entry>
- <entry>Checking out latest revision</entry>
- <entry>No meaningful difference</entry>
- <entry>No meaningful difference</entry>
+ <entry morerows="1">Performances</entry>
+ <entry>Extraire la dernière révision</entry>
+ <entry>Pas de différence significative</entry>
+ <entry>Pas de différence significative</entry>
</row>
<row>
- <entry>Large commits</entry>
- <entry>Slower overall, but cost is amortized across the
- lifetime of the commit</entry>
- <entry>Faster overall, but finalization delay may cause
- client timeouts</entry>
+ <entry>Grosses propagations</entry>
+ <entry>Globalement plus lent, mais mais cette lenteur est
+ répartie sur toute la durée de la propagation</entry>
+ <entry>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</entry>
</row>
</tbody>
</tgroup>
</table>
- <para>There are advantages and disadvantages to each of these
- two backend types. Neither of them is more
- <quote>official</quote> 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 <xref
- linkend="svn.reposadmin.basics.backends.tbl-1" />, 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.</para>
-
- <para>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.</para>
-
- <para>The following subsections provide a more detailed look at
- the available backend data store types.</para>
+ <para>Chaque type de magasin de données a ses avantages et ses
+ inconvénients. Aucun n'est plus <quote>officiel</quote> 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 <xref
+ linkend="svn.reposadmin.basics.backends.tbl-1" />, 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.</para>
+
+ <para>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.</para>
+
+ <para>Les paragraphes suivants abordent plus en détail les
+ différents types de magasins de données disponibles.</para>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-->
<sect3 id="svn.reposadmin.basics.backends.bdb">
<title>Berkeley DB</title>
- <para>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.</para>
-
- <para>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.</para>
-
- <para>Another great feature of Berkeley DB is <firstterm>hot
- backups</firstterm>—the ability to back up the
- database environment without taking it
- <quote>offline.</quote> We'll discuss how to back up your
- repository later in this chapter (in <xref
- linkend="svn.reposadmin.maint.backup"/>), but the benefits
- of being able to make fully functional copies of your
- repositories without any downtime should be obvious.</para>
-
- <para>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
- <firstterm>checkpoint</firstterm>—a location in the
- logfiles known not to be corrupt—and replay
- transactions until the data is restored to a usable state.
- See <xref linkend="svn.reposadmin.maint.diskspace"/> later
- in this chapter for more about Berkeley DB logfiles.</para>
-
- <para>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.</para>
-
- <para>While Berkeley DB promises to behave correctly on
- network shares that meet a particular set of specifications,
+ <para>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.</para>
+
+ <para>Le gestionnaire de bases de données Berkeley DB apporte un
+ support réel des transactions (c'est peut-être sa
***The diff for this file has been truncated for email.***
More information about the svnbook-dev
mailing list