[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