[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