[svnbook] r5261 committed - branches/1.8/fr/book/ch06-server-configuration. xml

chris-nanteuil at users.sourceforge.net chris-nanteuil at users.sourceforge.net
Sat Dec 17 06:29:27 CST 2016


Revision: 5261
          http://sourceforge.net/p/svnbook/source/5261
Author:   chris-nanteuil
Date:     2016-12-17 12:29:27 +0000 (Sat, 17 Dec 2016)
Log Message:
-----------
[fr] Chapter 6: translation completed.
needs cross-reading.

Modified Paths:
--------------
    branches/1.8/fr/book/ch06-server-configuration.xml

Modified: branches/1.8/fr/book/ch06-server-configuration.xml
===================================================================
--- branches/1.8/fr/book/ch06-server-configuration.xml	2016-12-13 10:50:05 UTC (rev 5260)
+++ branches/1.8/fr/book/ch06-server-configuration.xml	2016-12-17 12:29:27 UTC (rev 5261)
@@ -3508,7 +3508,8 @@
         this purpose, see the <filename>INSTALL</filename> file in
         the top level of the Subversion source code tree.</para>
 -->
-      <para>Vous pouvez accomplir les deux premières tâches ci-dessus
+      <para>Vous pouvez accomplir les deux premières tâches citées
+        <foreignphrase>supra</foreignphrase> 
         soit en compilant <command>httpd</command> et Subversion à
         partir du code source, soit en installant les paquets binaires
         précompilés correspondants sur votre système. Les informations
@@ -3577,7 +3578,8 @@
 -->
       <para>Apache interprète le chemin donné dans la directive
         <literal>LoadModule</literal> comme étant relatif à sa propre
-        racine. Si vous l'avez configuré comme indiqué ci-dessus,
+        racine. Si vous l'avez configuré comme indiqué 
+        <foreignphrase>supra</foreignphrase>,
         Apache cherchera le module Subversion DAV dans son propre
         sous-dossier <filename>modules/</filename>. En fonction de la
         façon dont Subversion a été installé sur votre machine, vous
@@ -6931,7 +6933,8 @@
 Committed revision 2.
 Copied properties for revision 2.
 …
-</screen>-->
+</screen>
+-->
           <screen>
 $ svnsync init http://esclave1.exemple.com/svn-proxy-sync \
                file://var/svn/depot
@@ -7700,8 +7703,9 @@
           </varlistentry>
 
           <varlistentry>
-            <term><literal>SVNCompressionLevel
-              <replaceable>level</replaceable></literal></term>
+            <term><literal>SVNCompressionLevel <!--
+              <replaceable>level</replaceable></literal></term> -->
+              <replaceable>niveau</replaceable></literal></term>
             <listitem>
 
 <!--
@@ -7722,8 +7726,9 @@
           </varlistentry>
 
           <varlistentry>
-            <term><literal>SVNIndexXSLT
-              <replaceable>directory-path</replaceable></literal></term>
+            <term><literal>SVNIndexXSLT <!--
+              <replaceable>directory-path</replaceable></literal></term> -->
+              <replaceable>chemin-vers-repertoire</replaceable></literal></term>
             <listitem>
 
 <!--
@@ -7738,8 +7743,9 @@
           </varlistentry>
 
           <varlistentry>
-            <term><literal>SVNInMemoryCacheSize
-              <replaceable>size</replaceable></literal></term>
+            <term><literal>SVNInMemoryCacheSize <!--
+              <replaceable>size</replaceable></literal></term> -->
+              <replaceable>taille</replaceable></literal></term>
             <listitem>
 
 <!--
@@ -7796,8 +7802,9 @@
           </varlistentry>
 
           <varlistentry>
-            <term><literal>SVNParentPath
-              <replaceable>directory-path</replaceable></literal></term>
+            <term><literal>SVNParentPath <!--
+              <replaceable>directory-path</replaceable></literal></term> -->
+              <replaceable>chemin-vers-repertoire</replaceable></literal></term>
             <listitem>
 
 <!--
@@ -7819,8 +7826,9 @@
           </varlistentry>
 
           <varlistentry>
-            <term><literal>SVNPath
-              <replaceable>directory-path</replaceable></literal></term>
+            <term><literal>SVNPath <!--
+              <replaceable>directory-path</replaceable></literal></term> -->
+              <replaceable>chemin-vers-repertoire</replaceable></literal></term>
             <listitem>
 
 <!--
@@ -7867,8 +7875,9 @@
           </varlistentry>
 
           <varlistentry>
-            <term><literal>SVNReposName
-              <replaceable>name</replaceable></literal></term>
+            <term><literal>SVNReposName <!--
+              <replaceable>name</replaceable></literal></term> -->
+              <replaceable>nom</replaceable></literal></term>
             <listitem>
 
 <!--
@@ -8566,6 +8575,7 @@
           au dépôt.</para>
       </warning>
 
+<!--
       <para>If you're using the <literal>SVNParentPath</literal>
         directive, it's important to specify the repository names in
         your sections.  If you omit them, a section such as
@@ -8575,13 +8585,33 @@
         directive, however, it's fine to provide only paths in your
         sections—after all, there's only one repository.</para>
 
+-->
+      <para>Si vous utilisez la directive
+        <literal>SVNParentPath</literal>, il est important de spécifier
+        les noms de dépôts dans vos sections. Si vous l'oubliez, à une 
+        section comme <literal>[/un/repertoire]</literal> correspondra
+        le chemin <filename>/un/repertoire</filename> dans 
+        <emphasis>chaque</emphasis> dépôt. Cependant, si vous utilisez 
+        la directive <literal>SVNPath</literal>, il suffit d'indiquer
+        les chemins dans vos sections (après tout, il n'y a qu'un seul
+        dépôt).</para>
+
+<!--
       <para>Permissions are inherited from a path's parent directory.
         That means we can specify a subdirectory with a different
         access policy for Sally.  Let's continue our previous
         example, and grant Sally write access to a child of the branch
         that she's otherwise permitted only to read:</para>
+-->
+      <para>Les droits sont hérités d'un répertoire parent dans le 
+        système de fichiers. Cela veut dire que vous pouvez spécifier
+        un sous-répertoire avec des droits différents pour Sally. Si 
+        nous continuons avec l'exemple précédent, nous pouvons autoriser
+        Sally à écrire vers un répertoire fils de la branche où elle
+        ne possède que des droits de lecture :</para>
 
       <informalexample>
+<!--
         <programlisting>
 [calc:/branches/calc/bug-142]
 harry = rw
@@ -8591,18 +8621,41 @@
 [calc:/branches/calc/bug-142/testing]
 sally = rw
 </programlisting>
+-->
+        <programlisting>
+[calc:/branches/calc/bug-142]
+harry = rw
+sally = r
+
+# Sally peut écrire seulement dans le sous-répertoire "test"
+[calc:/branches/calc/bogue-142/test]
+sally = rw
+</programlisting>
       </informalexample>
 
+<!--
       <para>Now Sally can write to the <filename>testing</filename>
         subdirectory of the branch, but can still only read other parts.
         Harry, meanwhile, continues to have complete read/write access
         to the whole branch.</para>
+-->
+      <para>Maintenant Sally peut écrire dans le sous-répertoire
+      <filename>test</filename> de la branche, mais ne peut toujours que
+      lire les autres parties. Harry, en attendant, continue à avoir les
+      droits d'accès complets en lecture écriture sur toute la
+      branche.</para>
 
+<!--
       <para>It's also possible to explicitly deny permission to someone
         via inheritance rules, by setting the username variable to
         nothing:</para>
+-->
+      <para>Il est aussi possible d'interdire explicitement l'accès à
+        quelqu'un grâce aux règles d'héritage, en attribuant la valeur
+        vide à un nom d'utilisateur :</para>
 
       <informalexample>
+<!--
         <programlisting>
 [calc:/branches/calc/bug-142]
 harry = rw
@@ -8610,29 +8663,63 @@
 
 [calc:/branches/calc/bug-142/secret]
 harry =
+</programlisting> 
+-->
+        <programlisting> 
+[calc:/branches/calc/bogue-142]
+harry = rw
+sally = r
+
+[calc:/branches/calc/bogue-142/secret]
+harry =
 </programlisting>
       </informalexample>
 
+<!--
       <para>In this example, Harry has read/write access to the
         entire <filename>bug-142</filename> tree, but has absolutely no
         access at all to the <filename>secret</filename> subdirectory
         within it.</para>
 
+-->
+      <para>Dans cet exemple, Harry a les droits de lecture/écriture sur
+      l'arborescence <filename>bogue-142</filename> toute entière, mais
+      n'a absolument pas accès au répertoire <filename>secret</filename>
+      contenu dans celle-ci.</para>
+
       <tip>
+<!--
         <para>The thing to remember is that the most specific path
           always matches first.  The server tries to match the path
           itself, and then the parent of the path, then the parent of
           that, and so on.  The net effect is that mentioning a specific
           path in the access file will always override any permissions
           inherited from parent directories.</para>
+-->
+        <para>Ce qu'il faut retenir est que le chemin le plus spécifique
+          est choisi en premier. Le serveur tente de trouver une
+          correspondance avec le chemin lui-même, puis avec son chemin
+          parent, puis avec le parent du parent, etc. Le résultat 
+          est que tout chemin spécifié dans le fichier des accès prendra 
+          le pas sur les droits hérités de ses répertoires 
+          parents.</para>
 
+<!--
         <para>Similarly, sections that specify a repository name have
           precedence over those that don't: if both
           <literal>[calc:/some/path]</literal> and
           <literal>[/some/path]</literal> are present, the former will be used
           and the latter ignored for <literal>calc</literal>.</para>
+-->
+        <para>De la même manière, les sections qui spécifient un nom de
+          dépôt sont prioritaires sur celles qui n'en spécifient 
+          pas : si  <literal>[calc:/un/chemin]</literal> et
+          <literal>[/un/chemin]</literal> sont présents, le premier
+          sera utilisé et le dernier ignoré pour 
+          <literal>calc</literal>.</para>
       </tip>
 
+<!--
       <para>By default, nobody has any access to any repository at all.
         That means that if you're starting with an empty file, you'll
         probably want to give at least read permission to all users at
@@ -8640,6 +8727,14 @@
         asterisk variable (<literal>*</literal>), which means <quote>all
         users</quote>:</para>
 
+-->
+      <para>Par défaut, personne n'a accès au dépôt. Cela signifie que 
+        si vous démarrez avec un fichier vide, vous voudrez probablement 
+        au moins donner les droits de lecture sur la racine du dépôt à 
+        tous les utilisateurs. Vous pouvez accomplir ceci en utilisant 
+        la variable astérisque (<literal>*</literal>), qui désigne
+        <quote>tous les utilisateurs</quote> :</para>
+
       <informalexample>
         <programlisting>
 [/]
@@ -8647,21 +8742,39 @@
 </programlisting>
       </informalexample>
 
+<!--
       <para>This is a common setup; notice that no repository
         name is mentioned in the section name.  This makes all repositories
         world-readable to all users.  Once all users have read access to
         the repositories, you can give explicit
         <literal>rw</literal> permission to certain users on specific
         subdirectories within specific repositories.</para>
+-->
+      <para>C'est une configuration très répandue ; notez qu'aucun
+        nom de dépôt n'est mentionné dans le nom de la section. Ceci 
+        rend tous les dépôts accessibles en lecture à tous les 
+        utilisateurs. Une fois que tous les utilisateurs ont l'accès en 
+        lecture aux dépôts, vous pouvez accorder des droits d'écriture
+        (<literal>rw</literal>) explicites à certains utilisateurs sur 
+        des sous-répertoires spécifiques à l'intérieur de dépôts 
+        spécifiques.</para>
 
+<!--
       <para>Note that while all of the previous examples use
         directories, that's only because defining access rules on
         directories is the most common case.  You may similarly
         restrict access on file paths, too.</para>
+-->
+      <para>Notez que, bien que tous les exemples 
+        <foreignphrase>supra</foreignphrase> font référence à des 
+        répertoires, c'est simplement parce qu'il est plus commun de
+        définir des droits d'accès sur des répertoires. Mais vous pouvez
+        également restreindre les accès sur des fichiers.</para>
 
       <informalexample>
-        <programlisting>
-[calendar:/projects/calendar/manager.ics]
+        <programlisting> <!--
+[calendar:/projects/calendar/manager.ics] -->
+[agenda:/projets/agenda/chef.ics]
 harry = rw
 sally = r
 </programlisting>
@@ -8672,8 +8785,12 @@
     <!-- =============================================================== -->
     <sect2 id="svn.serverconfig.pathbasedauthz.groups">
 
+<!--
       <title>Access Control Groups</title>
+-->
+      <title>Contrôle d'accès par groupes</title>
 
+<!--
       <para>The access file also allows you to define whole groups of
         users, much like the Unix <filename>/etc/group</filename>
         file.  To do this, create a <literal>groups</literal> section
@@ -8681,21 +8798,46 @@
         section: each variable's name defines the name of the group,
         and its value is a comma-delimited list of usernames which
         are part of that group.</para>
+-->
+      <para>Le fichier des accès vous permet aussi de définir des 
+        groupes entiers d'utilisateurs, à la façon du fichier Unix
+        <filename>/etc/group</filename>. Créez donc une section 
+        <literal>groups</literal> dans votre fichiers d'accès et 
+        décrivez vos groupes dans cette section : chaque nom de
+        variable définit le nom d'un groupe et la valeur est une liste
+        d'identifiants, séparés par des virgules, qui constituent les 
+        membres de ce groupe.</para>
 
       <informalexample>
+<!--
         <programlisting>
 [groups]
 calc-developers = harry, sally, joe
 paint-developers = frank, sally, jane
 everyone = harry, sally, joe, frank, jane
 </programlisting>
+-->
+        <programlisting>
+[groups]
+developpeurs-calc = harry, sally, joe
+developpeurs-paint = frank, sally, jane
+tout-le-monde = harry, sally, joe, frank, sally, jane
+</programlisting>
       </informalexample>
 
+<!--
       <para>Groups can be granted access control just like users.
         Distinguish them with an <quote>at sign</quote>
         (<literal>@</literal>) prefix:</para>
 
+-->
+      <para>Les droits d'accès peuvent être accordés aux groupes de la
+        même façon qu'à de simples utilisateurs. Il faut juste les 
+        mettre en évidence par le préfixe <quote>at</quote>
+        (<literal>@</literal>) :</para>
+
       <informalexample>
+<!--
         <programlisting>
 [calc:/projects/calc]
 @calc-developers = rw
@@ -8704,8 +8846,18 @@
 jane = r
 @paint-developers = rw
 </programlisting>
+-->
+        <programlisting>
+[calc:/projets/calc]
+ at developpeurs-calc = rw
+
+[paint:/projets/paint]
+jane = r
+ at developpeurs-paint = rw			
+</programlisting>
       </informalexample>
 
+<!--
       <para>Another important fact is that group permissions are not
         overridden by individual user permissions. Rather, the
         <emphasis>combination</emphasis> of all matching permissions is
@@ -8717,15 +8869,41 @@
         already has. Restricting users who are part of a group to less
         than their group's permissions is impossible.</para>
 
+-->
+      <para>Un autre fait notable est que les droits définis pour les 
+        groupes ne sont pas écrasés par les droits individuels. En fait,
+        c'est la <emphasis>combinaison</emphasis> de tous les droits qui
+        s'applique. Dans l'exemple précédent, Jane est membre du groupe
+       <literal>développeurs-paint</literal>, qui a les droits de
+       lecture/écriture. Combiné avec la règle 
+       <literal>jane = r</literal>, cela donne toujours les droits de
+       lecture/écriture à Jane. Les droits pour les membres d'un groupe
+       ne peuvent être que étendus au delà des droits du groupe. 
+       Restreindre les droits d'utilisateurs qui font partie d'un groupe
+       n'est pas possible.</para>
+
+<!--
       <para>Groups can also be defined to contain other groups:</para>
 
+-->
+      <para>Les groupes peuvent aussi contenir d'autres 
+        groupes :</para>
+
       <informalexample>
+<!--
         <programlisting>
 [groups]
 calc-developers = harry, sally, joe
 paint-developers = frank, sally, jane
 everyone = @calc-developers, @paint-developers
 </programlisting>
+-->
+    <programlisting>
+[groups]
+developpeurs-calc = harry, sally, joe
+developpeurs-paint = frank, sally, jane
+tout-le-monde = @developpeurs-calc, @developpeurs-paint
+</programlisting>
       </informalexample>
 
     </sect2>
@@ -8733,8 +8911,12 @@
     <!-- =============================================================== -->
     <sect2 id="svn.serverconfig.pathbasedauthz.aliases">
 
+<!--
       <title>Username Aliases</title>
+-->
+      <title>Alias</title>
 
+<!--
       <para>Some authentication systems expect and carry relatively
         short usernames of the sorts we've been describing
         here—<literal>harry</literal>,
@@ -8747,17 +8929,45 @@
         usernames like that, the access file can become quite bloated
         with long or obscure usernames that are easy to
         mistype.</para>
+-->
+      <para>Certains systèmes d'authentification attendent et utilisent 
+        des noms d'utilisateurs relativement courts tels que ceux que 
+        nous avons décrits ici — <literal>harry</literal>,
+        <literal>sally</literal>, <literal>joe</literal>, etc. Mais
+        d'autres systèmes d'authentification, comme par exemple ceux qui
+        utilisent des bases LDAP ou des certificats clients SSL, peuvent
+        utiliser des noms d'utilisateurs beaucoup plus complexes. Par
+        exemple, le nom d'utilisateur d'Harry dans un système protégé 
+        par LDAP pourrait très bien être : <literal>CN=Harold
+        Hacker,OU=Engineers,DC=red-bean,DC=com</literal>. Avec des noms
+        d'utilisateurs de ce type, le fichier des accès devient
+        rapidement illisible, avec des noms d'utilisateurs longs ou
+        obscurs qui peuvent facilement être mal orthographiés.</para>
 
+<!--
       <para>Fortunately, Subversion 1.5 introduced username aliases to
         the access file syntax.  Username aliases allow you to have to
         type the correct complex username only once, in a statement
         which assigns to it a more easily digestable alias.</para>
+  -->
+      <para>Heureusement, Subversion 1.5 a introduit les alias dans la
+        syntaxe du fichier de contrôle d'accès. Vous n'avez ainsi à 
+        taper le nom d'utilisateur complexe entier qu'une seule fois, au 
+        sein d'un paragraphe qui lui attribue un alias bien plus 
+        digeste.</para>
 
+<!--
       <para>Username aliases are defined in the
         special <literal>aliases</literal> section of the access file,
         with each variable name in that section defining an alias, and
         the value of those variables carrying the real Subversion
         username which is being aliased.</para>
+-->
+      <para>Les alias sont définis dans la section 
+        <literal>aliases</literal> du fichier de contrôle d'accès. 
+        Chaque nom de variable déclarée dans cette section définit un
+        alias et la valeur de cette variable est l'identifiant réel 
+        Subversion qui est derrière l'alias.</para>
 
       <informalexample>
         <programlisting>
@@ -8769,34 +8979,62 @@
 </programlisting>
       </informalexample>
 
+<!--
       <para>Once you've defined a set of aliases, you can refer to the
         users elsewhere in the access file via their aliases in all the
         same places you could have instead used their actual usernames.
         Simply prepend an ampersand to the alias to distinguish it from
         a regular username:</para>
+-->
+      <para>Une fois défini votre ensemble d'alias, vous pouvez faire
+        référence à ces utilisateurs en d'autres endroits du fichier par
+        leurs alias, partout là où vous auriez sinon entré leur
+        véritables noms d'utilisateurs. Il faut juste ajouter une
+        esperluette (<literal>&</literal>) juste avant l'alias pour 
+        le distinguer des noms d'utilisateurs classiques :</para>
 
       <informalexample>
+<!--		  
         <programlisting>
 [groups]
 calc-developers = &harry, &sally, &joe
 paint-developers = &frank, &sally, &jane
 everyone = @calc-developers, @paint-developers
 </programlisting>
+-->
+        <programlisting>
+[groups]
+developpeurs-calc = &harry, &sally, &joe
+developpeurs-paint = &frank, &sally, &jane
+tout-le-monde = @developpeurs-calc, @developpeurs-paint
+</programlisting>
       </informalexample>
 
+<!--
       <para>You might also choose to use aliases if your users'
         usernames change frequently.  Doing so allows you to need to
         update only the aliases table when these username changes occur,
         instead of doing global search-and-replace operations on the
         whole access file.</para>
+-->
+      <para>Vous pouvez aussi choisir d'utiliser des alias si les noms 
+        de vos utilisateurs changent souvent. Ainsi vous n'aurez que la 
+        table des alias à mettre à jour quand des modifications de noms
+        d'utilisateurs auront lieu, au lieu d'avoir à effectuer des
+        opérations de recherches-et-remplacements-globaux sur la 
+        totalité du fichier.</para>
 
     </sect2>
 
     <!-- =============================================================== -->
     <sect2 id="svn.serverconfig.pathbasedauthz.authclass-tokens">
 
+<!--
       <title>Advanced Access Control Features</title>
+-->
+      <title>Fonctionnalités avancées de contrôle d'accès</title>
 
+<!--
       <para>Beginning with Subversion 1.5, the access file syntax also
         supports some <quote>magic</quote> tokens for helping you to
         make rule assignments based on the user's authentication
@@ -8808,15 +9046,29 @@
         all.  Similarly employed is the <literal>$anonymous</literal>
         token, except that it matches everyone who has
         <emphasis>not</emphasis> authenticated with a username.</para>
+  -->
+      <para>À partir de Subversion 1.5, le fichier de contrôle d'accès 
+        reconnait aussi des mots-clés <quote>magiques</quote> afin de 
+        vous aider à créer des règles basées sur le statut 
+        d'authentification de l'utilisateurs. Ainsi le mot-clé
+        <literal>$authenticated</literal> est utilisé pour désigner un
+        utilisateur (quel qu'il soit) authentifié. Vous pouvez utiliser
+        ce mot-clé à la place d'un identifiant, d'un alias ou d'un nom
+        de groupe dans vos règles de contrôle d'accès. De la même 
+        manière, le mot-clé <literal>$anonymous</literal> désigne 
+        n'importe qui qui <emphasis>n'est pas</emphasis> 
+        authentifié.</para>
 
       <informalexample>
-        <programlisting>
-[calendar:/projects/calendar]
+        <programlisting><!--
+[calendar:/projects/calendar] -->
+[agenda:/projets/agenda]
 $anonymous = r
 $authenticated = rw
 </programlisting>
       </informalexample>
 
+  <!--
       <para>Another handy bit of access file syntax magic is the use
         of the tilde (<literal>~</literal>) character as an exclusion
         marker.  In your authorization rules, prefixing a username,
@@ -8825,18 +9077,34 @@
         do <emphasis>not</emphasis> match the rule.  Though somewhat
         unnecessarily obfuscated, the following block is equivalent to
         the one in the previous example:</para>
+  -->
+      <para>Un autre élément magique de la syntaxe des fichiers de 
+        contrôle d'accès est le caractère tilde (<literal>~</literal>) 
+        qui est un marqueur d'exclusion. Dans vos règles de contrôle
+        d'accès, si vous préfixez un identifiant, un alias, un groupe
+        ou un mot-clé d'authentification avec le caractère tilde, 
+        Subversion applique la règle aux utilisateurs qui 
+        <emphasis>ne vérifient pas</emphasis> la règle. Bien que 
+        inutilement complexe, le bloc suivant est équivalent à celui
+        du précédent exemple :</para>
 
       <informalexample>
-        <programlisting>
-[calendar:/projects/calendar]
+        <programlisting> <!--
+[calendar:/projects/calendar] -->
+[agenda:/projets/agenda]
 ~$authenticated = r
 ~$anonymous = rw
 </programlisting>
       </informalexample>
 
+<!--
       <para>A less obvious example might be as follows:</para>
+-->
+      <para>Un exemple moins simpliste pourrait ressembler 
+        à :</para>
 
       <informalexample>
+<!--		  
         <programlisting>
 [groups]
 calc-developers = &harry, &sally, &joe
@@ -8851,6 +9119,21 @@
 [calc:/projects/calc/tags]
 ~@calc-owners = r
 </programlisting>
+-->
+        <programlisting>
+[groups]
+developpeurs-calc = &harry, &sally, &joe
+proprios-calc = &hewlett, &packard
+calc = @developpeurs-calc, @proprios-calc
+
+# tous les participants à calc ont les droits de lecture/écriture ...
+[calc:/projets/calc]
+ at calc = rw
+
+# ...mais seuls les propriétaires peuvent faire et modifier des étiquettes.
+[calc:/projets/calc/tags]
+~@proprios-calc = r
+</programlisting>
       </informalexample>
 
     </sect2>
@@ -8858,13 +9141,25 @@
     <!-- =============================================================== -->
     <sect2 id="svn.serverconfig.pathbasedauthz.gotchas">
 
+<!--
       <title>Some Gotchas with Access Control</title>
+-->
 
+      <title>Embûches avec le contrôle d'accès</title>
+<!--
       <para>If you're using Apache as your Subversion server and have
         made certain subdirectories of your repository unreadable to
         certain users, you need to be aware of a possible nonoptimal
         behavior with <command>svn checkout</command>.</para>
 
+-->
+      <para>Si vous utilisez Apache en tant que serveur Subversion et 
+        que vous avez rendu certains sous-répertoires de votre dépôt
+        inaccessibles en lecture à certains utilisateurs, vous devez 
+        être au courant d'un comportement potentiellement non-optimal de 
+        la commande <command>svn checkout</command>.</para>
+
+<!--
       <para>Depending on which HTTP communication library the
         Subversion client is using, it may request that the entire
         payload of a checkout or update be delivered in a single
@@ -8881,7 +9176,26 @@
         subdirectory; thus the subdirectory is skipped altogether,
         rather than asking the user to reauthenticate as Sally at the
         right moment.</para>
+-->
+      <para>En fonction de la bibliothèque de communication HTTP que le 
+        client Subversion utilise, il envoie potentiellement une requête 
+        au serveur pour recevoir tout le contenu de l'extraction ou de 
+        la mise à jour dans une réponse unique (dont la taille peut être
+        assez importante). Quand le serveur reçoit la requête, c'est la
+        <emphasis>seule</emphasis> opportunité dont dispose Apache pour
+        demander à l'utilisateur de s'authentifier. Ceci a des effets
+        secondaires assez étonnants. Par exemple, si un certain 
+        sous-répertoire du dépôt n'est accessible en lecture qu'à 
+        l'utilisateur Sally et que l'utilisateur Harry extrait un 
+        répertoire parent, le client répondra à la demande 
+        d'authentification initiale en tant que Harry. Au fur et à 
+        mesure que le serveur génère la réponse, il n'a aucun moyen de
+        renvoyer un défi d'authentification quand il atteint le
+        sous-répertoire spécial ; ainsi le sous-répertoire tout
+        entier est omis, plutôt que de demander à l'utilisateur de se
+        ré-authentifier en tant que Sally le moment venu.</para>
 
+<!--
       <para>In a similar way, if the root of the repository is
         anonymously world-readable, the entire checkout will be done
         without authentication—again, skipping the unreadable
@@ -8890,6 +9204,16 @@
         post <emphasis>Authz and Anon Authn Agony</emphasis> at
         <ulink url="http://blogs.collab.net/subversion/2007/03/authz_and_anon_/"
         />.</para></footnote></para>
+-->
+      <para>De même, si la racine du dépôt est accessible en lecture 
+        anonymement, l'extraction se fera entièrement sans 
+        authentification, omettant, encore une fois, le répertoire 
+        non-lisible, plutôt que d'envoyer une demande 
+        d'authentification au cours de l'opération<footnote><para>Pour
+        plus d'informations sur ce comportement, lisez l'article de blog 
+        <emphasis>Authz and Anon Authn Agony</emphasis> sur
+        <ulink url="http://blogs.collab.net/subversion/2007/03/authz_and_anon_/"
+        /> (article en anglais).</para></footnote>.</para>
       <!-- TODO: Merge content from the blog post into the book. -->
 
     </sect2>
@@ -8899,41 +9223,82 @@
   <!-- ================================================================= -->
   <!-- ================================================================= -->
   <sect1 id="svn.serverconfig.operational-logging">
+<!--
     <title>High-level Logging</title>
+-->
+    <title>Journalisation du haut-niveau</title>
 
+<!--
     <para>Both the Apache <command>httpd</command>
       and <command>svnserve</command> Subversion servers provide
       support for high-level logging of Subversion operations.
       Configuring each of the server options to provide this level of
       logging is done differently, of course, but the output from each
       is designed to conform to a uniform syntax.</para>
+-->
+    <para>À la fois Apache <command>httpd</command> et 
+      Subversion <command>svnserve</command> offrent la possibilité de
+      journaliser les opérations Subversion à un haut-niveau. La 
+      configuration de chacun des serveurs pour obtenir ce niveau de
+      journalisation se fait différemment, bien sûr, mais les deux
+      produisent des sorties qui respectent une syntaxe uniforme.</para>
 
+<!--
     <para>To enable high-level logging in <command>svnserve</command>,
-      you need only use the <option>--log-file</option> command-line
+      you need only use the <option>- -log-file</option> command-line
       option when starting the server, passing as the value to the
       option the file to which <command>svnserve</command> should
       write its log output.</para>
+-->
+    <para>Pour active la journalisation de haut-niveau de
+      <command>svnserve</command>, vous n'avez qu'à utiliser l'option
+      <option>--log-file</option> de la ligne de commande quand vous
+      démarrer le serveur, en indiquant en paramètre de l'option le
+      fichier vers lequel <command>svnserve</command> doit écrire la
+      journalisation.</para>
 
     <informalexample>
+<!--		
       <screen>
-$ svnserve -d -r /path/to/repositories --log-file /var/log/svn.log
+$ svnserve -d -r /path/to/repositories - -log-file /var/log/svn.log
 </screen>
+-->
+      <screen>
+$ svnserve -d -r /chemin/vers/depots --log-file /var/log/svn.log
+</screen>
     </informalexample>
 
+<!--
     <para>Enabling the same in Apache is a bit more involved, but is
       essentially an extension of Apache's stock log output
       configuration mechanisms—see
       <xref linkend="svn.serverconfig.httpd.extra.logging"/> for
       details.</para>
+-->
+    <para>Activer cette journalisation dans Apache est un peu plus 
+      compliqué, mais cela ne reste qu'une extension de la configuration
+      de la journalisation Apache de base (reportez-vous à
+      <xref linkend="svn.serverconfig.httpd.extra.logging"/> pour plus 
+      de détails).</para>
 
+<!--
     <para>The following is a list of Subversion action log messages
       produced by its high-level logging mechanism, followed by one or
       more examples of the log message as it appears in the log
       output.</para>
+-->
+    <para>Ce qui suit est une liste de messages de journalisation des
+      actions Subversion produite par le mécanisme de journalisation
+      de haut-niveau, suivi par un ou plusieurs exemples des 
+      messages de journalisation tels qu'ils apparaissent dans les
+      journaux.</para>
 
     <variablelist>
       <varlistentry>
+<!--
         <term>Checkout or export</term>
+-->
+        <term>Extraction ou export</term>
         <listitem>
           <programlisting>
 checkout-or-export /path r62 depth=infinity
@@ -8941,7 +9306,10 @@
         </listitem>
       </varlistentry>
       <varlistentry>
+<!--
         <term>Commit</term>
+-->
+        <term>Propagation</term>
         <listitem>
           <programlisting>
 commit harry r100
@@ -8958,7 +9326,10 @@
         </listitem>
       </varlistentry>
       <varlistentry>
+<!--
         <term>Fetch a directory</term>
+-->
+        <term>Parcours d'un répertoire</term>
         <listitem>
           <programlisting>
 get-dir /trunk r17 text
@@ -8966,7 +9337,10 @@
         </listitem>
       </varlistentry>
       <varlistentry>
+<!--
         <term>Fetch a file</term>
+-->
+        <term>Parcours d'un fichier</term>
         <listitem>
           <programlisting>
 get-file /path r20 props
@@ -8974,7 +9348,10 @@
         </listitem>
       </varlistentry>
       <varlistentry>
+<!--
         <term>Fetch a file revision</term>
+-->
+        <term>Parcours d'une révision d'un fichier</term>
         <listitem>
           <programlisting>
 get-file-revs /path r12:15 include-merged-revisions
@@ -8982,7 +9359,10 @@
         </listitem>
       </varlistentry>
       <varlistentry>
+<!--
         <term>Fetch merge information</term>
+-->
+        <term>Parcours des informations de fusion</term>
         <listitem>
           <programlisting>
 get-mergeinfo (/path1 /path2)
@@ -8990,7 +9370,10 @@
         </listitem>
       </varlistentry>
       <varlistentry>
+<!--
         <term>Lock</term>
+-->
+        <term>Verrouillage</term>
         <listitem>
           <programlisting>
 lock /path steal
@@ -8998,7 +9381,10 @@
         </listitem>
       </varlistentry>
       <varlistentry>
+<!--
         <term>Log</term>
+-->
+        <term>Journalisation</term>
         <listitem>
           <programlisting>
 log (/path1,/path2,/path3) r20:90 discover-changed-paths revprops=()
@@ -9006,7 +9392,10 @@
         </listitem>
       </varlistentry>
       <varlistentry>
+<!--
         <term>Replay revisions (svnsync)</term>
+-->
+        <term>Rejeu d'une révision (svnsync)</term>
         <listitem>
           <programlisting>
 replay /path r19
@@ -9014,7 +9403,10 @@
         </listitem>
       </varlistentry>
       <varlistentry>
+<!--
         <term>Revision property change</term>
+-->
+        <term>Modification des propriétés de révision</term>
         <listitem>
           <programlisting>
 change-rev-prop r50 propertyname
@@ -9022,7 +9414,10 @@
         </listitem>
       </varlistentry>
       <varlistentry>
+<!--
         <term>Revision property list</term>
+-->
+        <term>Liste des propriétés de révision</term>
         <listitem>
           <programlisting>
 rev-proplist r34
@@ -9038,7 +9433,10 @@
         </listitem>
       </varlistentry>
       <varlistentry>
+<!--
         <term>Switch</term>
+-->
+        <term>Bascule vers une nouvelle URL (switch)</term>
         <listitem>
           <programlisting>
 switch /pathA /pathB at 50 depth=infinity
@@ -9046,7 +9444,10 @@
         </listitem>
       </varlistentry>
       <varlistentry>
+<!--
         <term>Unlock</term>
+-->
+        <term>Déverrouillage</term>
         <listitem>
           <programlisting>
 unlock /path break
@@ -9054,7 +9455,10 @@
         </listitem>
       </varlistentry>
       <varlistentry>
+<!--
         <term>Update</term>
+-->
+        <term>Mise à jour</term>
         <listitem>
           <programlisting>
 update /path r17 send-copyfrom-args
@@ -9063,12 +9467,21 @@
       </varlistentry>
     </variablelist>
 
+<!--
     <para>As a convenience to administrators who wish to post-process
       their Subversion high-level logging output (perhaps for
       reporting or analysis purposes), Subversion source code
       distributions provide a Python module (located at
       <filename>tools/server-side/svn_server_log_parse.py</filename>)
       which can be used to parse Subversion's log output.</para>
+-->
+    <para>Afin de faciliter le travail des administrateurs qui 
+      souhaitent effectuer des traitements sur leurs journaux (pour
+      produire des rapports ou les analyser), le code source de 
+      Subversion est fourni avec un module Python (situé à
+      <filename>tools/server-side/svn_server_log_parse.py</filename>)
+      qui peut être utilisé pour analyser la journalisation produite
+      par Subversion.</para>
 
   </sect1>
 
@@ -9076,8 +9489,12 @@
   <!-- ================================================================= -->
   <!-- ================================================================= -->
   <sect1 id="svn.serverconfig.optimization">
+<!--
     <title>Server Optimization</title>
+-->
+    <title>Optimisation du serveur</title>
 
+<!--
     <para>Part of the due diligence when offering a service such as a
       Subversion server involves capacity planning and performance
       tuning.  Subversion doesn't tend to be particularly greedy in
@@ -9089,11 +9506,27 @@
       use….</para></footnote>.  In this section, we'll discuss
       some ways you can tweak your Subversion server configuration
       to offer even better performance and scalability.</para>
+-->
+    <para>Les développeurs de Subversion n'envisagent pas de fournir un
+      service tel que le serveur Subversion sans pouvoir configurer
+      finement celui-ci. Subversion n'est pas particulièrement gourmand
+      en termes de ressources mémoire ou processeur, mais chaque service
+      gagne à être optimisé, surtout quand l'utilisation de ce service
+      explose<footnote><para>Dans le cas de Subversion, l'explosion est
+      due, bien sûr, à son nom très cool. Et aussi à sa popularité, sa
+      fiabilité, sa facilité d'utilisation, …</para></footnote>.
+      Dans cette section, nous exposons quelques manières d'ajuster la
+      configuration du serveur Subversion pour offrir encore davantage
+      de performance et de capacité à monter en charge.</para>
 
     <!-- =============================================================== -->
     <sect2 id="svn.serverconfig.optimization.caching">
+<!--
       <title>Data Caching</title>
+-->
+      <title>Mise en cache des données</title>
 
+<!--
       <para>Generally speaking, the most expensive part of a
         Subversion server's job is fetching data from the repository.
         Subversion 1.6 attempted to offset this cost by introducing
@@ -9103,19 +9536,49 @@
         operations, but also by providing in each of the available
         servers the means by which fine-tune the size and some
         behaviors of the cache.</para>
+-->
+      <para>Généralement, le travail le plus coûteux du serveur 
+        Subversion consiste à récupérer les données dans le dépôt.
+        Subversion 1.6 essayait de réduire ce coût en introduisant la
+        mise en cache en mémoire de certains types de données qu'il
+        lisait dans le dépôt. Subversion 1.7 va un cran plus loin, en
+        mettant en cache non seulement le résultat de certaines des
+        opérations les plus coûteuses mais aussi en offrant les moyens
+        de configurer finement la taille et le comportement du cache
+        pour tous les serveurs.</para>
 
+<!--
       <para>For <command>svnserve</command>, you can specify the size
-        of the cache using the <option>--memory-cache-size</option>
+        of the cache using the <option>- -memory-cache-size</option>
         (<option>-M</option>) command-line option.  You can also
         dictate whether <command>svnserve</command> should attempt to
         cache content fulltexts and deltas via the
-        boolean <option>--cache-fulltexts</option>
-        and <option>--cache-txdeltas</option> options,
+        boolean <option>- -cache-fulltexts</option>
+        and <option>- -cache-txdeltas</option> options,
         respectively.</para>
+-->
+      <para>Pour <command>svnserve</command>, vous pouvez spécifier la
+        taille du cache en utilisant l'option
+        <option>--memory-cache-size</option> (<option>-M</option>)
+        de la ligne de commande. Vous pouvez aussi imposer à 
+        <command>svnserve</command> de mettre en cache le texte complet
+        (resp. les deltas calculés) <foreignphrase>via</foreignphrase> 
+        l'option <option>--cache-fulltexts</option> (resp. 
+        <option>--cache-txdeltas</option>).</para>
 
       <informalexample>
+<!--		  
         <screen>
 $ svnserve -d -r /path/to/repositories \
+           - -memory-cache-size 1024 \
+           - -cache-txdeltas yes \
+           - -cache-fulltexts yes
+…
+$
+</screen>
+-->
+        <screen>
+$ svnserve -d -r /chemin/vers/depots \
            --memory-cache-size 1024 \
            --cache-txdeltas yes \
            --cache-fulltexts yes
@@ -9124,6 +9587,7 @@
 </screen>
       </informalexample>
 
+<!--
       <para><command>mod_dav_svn</command> provides the same degree of
         cache configurability via <filename>httpd.conf</filename>
         directives.
@@ -9132,8 +9596,17 @@
         and <literal>SVNCacheTextDeltas</literal> directives may be
         used at the server configuration level to control Subversion's
         data cache characteristics:</para>
+-->
+      <para><command>mod_dav_svn</command> est configurable de la même
+        manière à travers les directives de 
+        <filename>httpd.conf</filename>. Les directives 
+        <literal>SVNInMemoryCacheSize</literal>,
+        <literal>SVNCacheFullTexts</literal> et
+        <literal>SVNCacheTextDeltas</literal> peuvent être utilisées 
+        pour définir les caractéristiques du cache de données.</para>
 
       <informalexample>
+<!--
         <programlisting>
 <IfModule dav_svn_module>
   # Enable a 1 Gb Subversion data cache for both fulltext and deltas.
@@ -9142,8 +9615,18 @@
   SVNCacheFullTexts On
 </IfModule>
 </programlisting>
+-->
+        <programlisting>
+<IfModule dav_svn_module>
+  # Autorise 1 Go de cache de données pour le texte et les deltas.
+  SVNInMemoryCacheSize 1048576
+  SVNCacheTextDeltas On
+  SVNCacheFullTexts On
+</IfModule>
+</programlisting>
       </informalexample>
 
+<!--
       <para>So what settings should you use?  Certainly you need to
         consider what resources are available on your server.  To get
         any benefit out of the cache at all, you'll probably want to
@@ -9151,26 +9634,48 @@
         which are most commonly accessed in your repository (for
         example, your project's <filename>trunk</filename> directory
         tree).</para>
+-->
+      <para>Alors quels réglages utiliser ? Vous devez déjà 
+        prendre en compte les ressources dont dispose votre serveur.
+        Pour obtenir un gain avec le cache, vous devrez probablement
+        avoir un cache capable de contenir tous les fichiers dont les
+        accès sont réguliers dans votre dépôt (par exemple, la 
+        sous-arborescence <filename>trunk</filename> de votre 
+        projet).</para>
 
       <tip>
+<!--
         <para>Setting the memory cache size to <literal>0</literal>
           will disable this enhanced caching mechanism and cause
           Subversion to fall back to using the older cache mechanisms
           introduced in Subversion 1.6.</para>
+-->
+        <para>Spécifier une taille de cache de 
+          <literal>0</literal> désactive le mécanisme de cache évolué et
+          entraine l'utilisation du mécanisme de cache introduit par la
+          version 1.6 de Subversion.</para>
       </tip>
 
       <note>
+<!--
         <para>Currently, only repositories which make use of the FSFS
           backend data store make use of this data caching
           functionality.</para>
+-->
+        <para>Actuellement, seuls les dépôts utilisant le magasin de
+          données FSFS mettent en œuvre le mécanisme de cache.</para>
       </note>
 
     </sect2>
 
     <!-- =============================================================== -->
     <sect2 id="svn.serverconfig.optimization.compression">
+<!--
       <title>Network Compression of Data</title>
+-->
+      <title>Compression des données sur le réseau</title>
 
+<!--
       <para>Compressing the data transmitted across the wire can
         greatly reduce the size of those network transmissions, but
         comes at the cost of server (and client) CPU cycles.
@@ -9180,14 +9685,31 @@
         tune just how hard your server will work to compress the data
         it sends across the wire.  To assist with this fine tuning
         process, Subversion 1.7 offers
-        the <option>--compression</option> (<option>-c</option>)
+        the <option>- -compression</option> (<option>-c</option>)
         option to <command>svnserve</command> and
         the <literal>SVNCompressionLevel</literal> directive
         for <command>mod_dav_svn</command>.  Both accept a value which
         is an integer between 0 and 9 (inclusive), where 9 offers the
         best compression of wire data, and 0 disables compression
         altogether.</para>
+-->
+      <para>Compresser les données qui transitent sur le réseau peut
+        réduire significativement la taille des données transmises, au
+        détriment d'une consommation CPU sur le serveur et le client.
+        En fonction de la capacité du processeur de votre serveur, des
+        données que récupèrent vos clients sur vos serveurs et de la
+        bande passante disponible sur le réseau, il peut être avantageux
+        d'ajuster le taux de compression défini sur votre serveur avant
+        d'envoyer les données sur le réseau. Pour vous aider dans cette
+        phase de configuration, Subversion 1.7 propose l'option
+        <option>--compression</option> (<option>-c</option>) pour
+        <command>svnserve</command> et la directive 
+        <literal>SVNCompressionLevel</literal> pour
+        <command>mod_dav_svn</command>. Les deux acceptent une valeur
+        entière comprise entre 0 et 9 (inclus), 9 offrant la plus grande
+        compression et 0 désactivant toute compression.</para>
 
+<!--
       <para>For example, on a local area network (LAN) with 1-Gigabit
         connections, it might not make sense to have the server
         compress its network transmissions (which also forces the
@@ -9197,6 +9719,15 @@
         accessed primarily by clients with low-bandwidth connections
         would be doing those clients a favor by minimizing the overall
         size of its network communications.</para>
+-->
+      <para>Par exemple, sur un réseau local (LAN) Gigabit, il n'est pas
+        pertinent de compresser les données (qui doivent être aussi
+        décompressées par les clients) car le réseau est tellement
+        rapide que les utilisateurs ne verront pas le gain de diminuer
+        la charge réseau. En revanche, les serveurs dont les clients
+        sont connectés <foreignphrase>via</foreignphrase> des connexions
+        bas débit seront bien inspirés de minimiser les flux réseau
+        vers ces clients.</para>
 
     </sect2>
 
@@ -9207,39 +9738,77 @@
   <!-- ================================================================= -->
   <sect1 id="svn.serverconfig.multimethod">
 
+<!--
     <title>Supporting Multiple Repository Access Methods</title>
+-->
+    <title>Accès au dépôt par plusieurs méthodes</title>
 
+<!--
     <para>You've seen how a repository can be accessed in many
       different ways.  But is it possible—or safe—for your
       repository to be accessed by multiple methods simultaneously?
       The answer is yes, provided you use a bit of foresight.</para>
 
+-->
+    <para>Nous venons de voir différentes méthodes d'accès à un dépôt.
+      Est-il possible — et sans danger — d'accéder
+      simultanément à un dépôt par différentes méthodes ? La
+      réponse est oui, à condition d'être un petit peu prévoyant.</para>
+
+<!--
     <para>At any given time, these processes may require read and
       write access to your repository:</para>
 
+-->
+    <para>À un instant donné, les processus suivants peuvent avoir
+      besoin de l'accès en lecture ou en écriture au dépôt :</para>
+
     <itemizedlist>
       <listitem>
+<!--
         <para>Regular system users using a Subversion client (as
           themselves) to access the repository directly via
           <literal>file://</literal> URLs</para>
+-->
+        <para>des utilisateurs classiques du système se connectant à
+          l'aide d'un client Subversion à des URL
+          <literal>file://</literal> sous leur propre 
+          identité ;</para>
       </listitem>
       <listitem>
+<!--
         <para>Regular system users connecting to SSH-spawned private
           <command>svnserve</command> processes (running as
           themselves), which access the repository</para>
+-->
+        <para>des utilisateurs classiques du système se connectant à des
+          processus <command>svnserve</command> privés générés par SSH
+          (dont le propriétaire est l'utilisateur lui-même) et accédant
+          au dépôt ;</para>
       </listitem>
       <listitem>
+<!--
         <para>An <command>svnserve</command> process—either a
           daemon or one launched by
           <command>inetd</command>—running as a particular fixed
           user</para>
+-->
+        <para>un processus <command>svnserve</command> — soit un
+          serveur autonome, soit un processus lancé par
+          <command>inetd</command> — dont le propriétaire est un
+          utilisateur dédié ;</para>
       </listitem>
       <listitem>
+<!--
         <para>An Apache <command>httpd</command> process, running as a
           particular fixed user</para>
+-->
+        <para>un processus <command>httpd</command> Apache, dont le
+          propriétaire est un utilisateur dédié.</para>
       </listitem>
     </itemizedlist>
 
+<!--
     <para>The most common problem administrators run into is
       repository ownership and permissions.  Does every process (or
       user) in the preceding list have the rights to read and write the
@@ -9251,6 +9820,21 @@
       process may write to the database files using an unfriendly
       umask—one that prevents access by other users.</para>
 
+-->
+    <para>Les problèmes les plus courants rencontrés par les
+      administrateurs sont des problèmes de droits et de propriété pour
+      le dépôt. Chaque processus de la liste précédente a-t-il les
+      droits de lecture et d'écriture sur les fichiers sous-jacents du
+      dépôt ? En supposant que vous ayez un système d'exploitation
+      de type Unix, une approche naïve de ce problème serait de placer
+      chaque utilisateur potentiel du dépôt dans un groupe
+      <literal>svn</literal> unique et de faire posséder le dépôt tout
+      entier par ce groupe. Mais cela ne suffit même pas, car un
+      processus risque de modifier les fichiers de la base de données en
+      utilisant un umask inadapté qui va interdire l'accès aux autres
+      utilisateurs.</para>
+
+<!--
     <para>So the next step beyond setting up a common group for
       repository users is to force every repository-accessing process
       to use a sane umask.  For users accessing the repository
@@ -9262,6 +9846,21 @@
       002</userinput> command to Apache's own startup script,
       <filename>apachectl</filename>.  For example:</para>
 
+-->
+    <para>L'étape suivante consiste donc, après avoir mis en place un
+      groupe commun pour les utilisateurs du dépôt, à forcer tout
+      processus qui accède au dépôt à utiliser un umask correct. Pour
+      les utilisateurs qui accèdent directement au dépôt, vous pouvez
+      <quote>envelopper</quote> le programme svnserve dans un script
+      (<foreignphrase>wrapper</foreignphrase> en anglais) qui commence
+      par lancer la commande <userinput>umask 002</userinput>
+      et qui, seulement ensuite, appelle
+      le véritable programme client <command>svn</command>.
+      Vous pouvez également écrire un script similaire pour le programme
+      <command>svnserve</command> et ajouter la commande
+      <userinput>umask 002</userinput> au script de démarrage d'Apache,
+      <filename>apachectl</filename>. Par exemple :</para>
+
     <informalexample>
       <screen>
 $ cat /usr/bin/svn
@@ -9273,6 +9872,7 @@
 </screen>
     </informalexample>
 
+<!--
     <para>Another common problem is often encountered on Unix-like
       systems.  If your repository is backed by Berkeley DB, for
       example, it occasionally creates new log files to journal its
@@ -9285,12 +9885,36 @@
       newly created log files to have the same group owner as the
       parent directory.</para>
 
+-->
+    <para>Sur les systèmes de type Unix, on rencontre souvent un autre
+      problème classique. Si vous avez un dépôt Berkeley DB, par
+      exemple, il crée de temps en temps de nouveaux fichiers pour la
+      journalisation. Même si le dépôt Berkeley DB est entièrement
+      possédé par le groupe <literal>svn</literal>, ces nouveaux
+      journaux ne seront pas nécessairement possédés par le même groupe,
+      ce qui crée des problèmes de droits supplémentaires pour vos
+      utilisateurs. Une bonne façon de contourner ce problème est
+      d'activer le bit SUID du groupe sur le répertoire
+      <filename>db</filename> du dépôt, ce qui a pour résultat que tous
+      les nouveaux fichiers journaux créés ont le même propriétaire que
+      le répertoire parent.</para>
+
+<!--
     <para>Once you've jumped through these hoops, your repository
       should be accessible by all the necessary processes.  It may
       seem a bit messy and complicated, but the problems of having
       multiple users sharing write access to common files are classic
       ones that are not often elegantly solved.</para>
 
+-->
+    <para>Une fois ces manipulations effectuées, vos dépôts devraient
+      être accessibles par tous les processus nécessaires. Tout ceci
+      peut sembler un petit peu confus et compliqué, mais les problèmes
+      d'accès en écriture par plusieurs utilisateurs à des fichiers
+      partagés sont des problèmes très classiques, qui ne sont pas
+      souvent résolus avec élégance.</para>
+
+<!--
     <para>Fortunately, most repository administrators will never
       <emphasis>need</emphasis> to have such a complex configuration.
       Users who wish to access repositories that live on the same
@@ -9304,9 +9928,29 @@
       We recommend that you choose a single server that best meets your
       needs and stick with it!</para>
 
+-->
+    <para>Heureusement, la plupart des administrateurs
+      <emphasis>n'auront jamais besoin</emphasis> d'une configuration
+      aussi complexe. Les utilisateurs qui désirent accéder aux dépôts
+      résidant sur une même machine ne sont pas limités aux URL d'accès
+      <literal>file://</literal> — ils peuvent généralement
+      contacter le serveur http Apache ou le
+      serveur <command>svnserve</command> en utilisant
+      <literal>localhost</literal> comme nom de serveur dans leurs URL
+      <literal>http://</literal> ou <literal>svn://</literal>. Et
+      assurer la maintenance de plusieurs processus serveurs pour vos
+      dépôts Subversion vous créera plus de soucis qu'autre chose. Nous
+      vous recommandons de choisir un seul serveur (celui qui correspond
+      le mieux à vos besoins) et de vous y tenir !</para>
+
     <sidebar>
+<!--
       <title>The svn+ssh:// Server Checklist</title>
+-->
+      <title>Serveur <literal>svn+ssh://</literal> : les points à
+        vérifierDie Checkliste für svn+ssh://-Server</title>
 
+<!--
       <para>It can be quite tricky to get a bunch of users with
         existing SSH accounts to share a repository without
         permissions problems.  If you're confused about all the things
@@ -9314,19 +9958,42 @@
         system, here's a quick checklist that resummarizes some of the
         topics discussed in this section:</para>
 
+-->
+      <para>Partager un dépôt entre des utilisateurs qui ont des comptes
+        SSH sans avoir de problème de droits d'accès peut être assez
+        épineux. Si l'ensemble des tâches à mener par l'administrateur
+        d'un système de type Unix est encore un peu confus pour vous,
+        voici la liste des choses à vérifier qui récapitule les points
+        abordés dans cette section :</para>
+
       <itemizedlist>
         <listitem>
+<!--
           <para>All of your SSH users need to be able to read and
             write to the repository, so put all the SSH users into a
             single group.</para>
+-->
+          <para>tous vos utilisateurs SSH doivent être capables de lire
+            et d'écrire dans le dépôt, donc mettez tous les utilisateurs
+            SSH dans un même groupe ;</para>
         </listitem>
         <listitem>
+<!--
           <para>Make the repository wholly owned by that group.</para>
+-->
+          <para>
+            faites de ce dépôt l'entière propriété de ce groupe ;
+          </para>
         </listitem>
         <listitem>
+<!--
           <para>Set the group permissions to read/write.</para>
+-->
+          <para>mettez les droits d'accès de ce groupe à
+            lecture/écriture ;</para>
         </listitem>
         <listitem>
+<!--
           <para>Your users need to use a sane umask when accessing the
             repository, so make sure <command>svnserve</command>
             (<filename>/usr/bin/svnserve</filename>, or wherever it
@@ -9334,12 +10001,28 @@
             script that runs <userinput>umask 002</userinput> and
             executes the real <command>svnserve</command>
             binary.</para>
+-->
+          <para>vos utilisateurs doivent utiliser un umask correct quand
+            ils accèdent au dépôt, donc assurez-vous que
+            <command>svnserve</command>
+            (<filename>/usr/bin/svnserve</filename> ou le chemin vers
+              lequel <literal>$PATH</literal> pointe) est en fait un
+              script qui exécute <userinput>umask 002</userinput> avant
+              de lancer le véritable exécutable
+              <command>svnserve</command> ;</para>
         </listitem>
         <listitem>
+<!--
           <para>Take similar measures when using
             <command>svnlook</command> and
             <command>svnadmin</command>.  Either run them with a sane
             umask or wrap them as just described.</para>
+-->
+          <para>prenez des mesures similaires quand vous utilisez
+            <command>svnlook</command> et
+            <command>svnadmin</command> : soit vous les lancez avec
+            un umask correct, soit vous les <quote>enveloppez</quote>
+            dans un script comme nous venons de l'expliquer.</para>
         </listitem>
       </itemizedlist>
 




More information about the svnbook-dev mailing list