[svnbook] r5243 committed - branches/1.8/fr/book/ch06-server-configuration. xml
chris-nanteuil at users.sourceforge.net
chris-nanteuil at users.sourceforge.net
Wed Nov 30 11:32:32 CST 2016
Revision: 5243
http://sourceforge.net/p/svnbook/source/5243
Author: chris-nanteuil
Date: 2016-11-30 17:32:31 +0000 (Wed, 30 Nov 2016)
Log Message:
-----------
[fr] Chapter 6: translation in progress.
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-11-29 09:18:55 UTC (rev 5242)
+++ branches/1.8/fr/book/ch06-server-configuration.xml 2016-11-30 17:32:31 UTC (rev 5243)
@@ -6445,6 +6445,7 @@
rotation des journaux et l'archivage qui leur convient le
mieux.</para>
+ <!--
<para>But what if Subversion is simply generating too much log
information to be useful? For example, in
<xref linkend="svn.serverconfig.httpd.perf.bulk-updates" />,
@@ -6456,7 +6457,22 @@
might not have been). In this case, you might consider
using some Apache configuration magic to selectively silence
some of that log activity.</para>
+-->
+ <para>Mais que faire si Subversion génère simplement trop de
+ journaux pour pouvoir les exploiter ? Par exemple, dans
+ <xref linkend="svn.serverconfig.httpd.perf.bulk-updates" />,
+ nous avons indiqué que certaines approches que les clients
+ Subversion utilisent pour leurs extractions ou d'autres
+ opérations de mise à jour peuvent faire grandir rapidement la
+ taille des journaux parce que chaque requête, pour chaque
+ information élémentaire de la mise à jour, est journalisée
+ (alors que ce n'était pas le cas pour les versions précédentes
+ de Subversion). Dans ce cas, vous devriez envisager une
+ configuration très particulière d'Apache pour ne pas
+ journaliser, de manière sélective, l'ensemble des
+ activités.</para>
+<!--
<para>Apache HTTP Server's
<literal>mod_setenvif</literal> module offers
a <literal>SetEnvIf</literal> directive which is handy for
@@ -6468,8 +6484,21 @@
to <emphasis>not</emphasis> log <literal>GET</literal>
and <literal>PROPFIND</literal> requests aimed at private
Subversion URLs.</para>
+-->
+ <para>Le module <literal>mod_setenvif</literal> du serveur HTTP
+ Apache propose une directive <literal>SetEnvIf</literal> qui
+ est utile pour définir de manière conditionnelle des variables
+ d'environnement. Ainsi, la directive
+ <literal>CustomLog</literal> peut être configurée pour ne
+ journaliser que certaines requêtes en fonction de la valeur de
+ variables d'environnement. Vous trouverez un exemple de
+ configuration qui demande au serveur de <emphasis>ne
+ pas journaliser</emphasis> les requêtes <literal>GET</literal>
+ et <literal>PROPFIND</literal> visant des URL Subversion
+ privées.</para>
<informalexample>
+<!--
<programlisting>
# Matches everything, just to initialize the "in_repos" variable.
SetEnvIf Request_URI "^" in_repos=0
@@ -6487,8 +6516,28 @@
# Log requests, but only if "do_not_log" isn't set.
CustomLog logs/access_log env=!do_not_log
</programlisting>
+-->
+ <programlisting>
+# Correspondance pour tout, juste pour initialiser la variable 'dans_depot'.
+SetEnvIf Request_URI "^" dans_depot=0
+
+# Activer "dans_depot" si la requête pointe vers une URL Subversion privée.
+SetEnvIf Request_URI "/!svn/" dans_depot=1
+
+# Désactiver "ne_pas_journaliser" pour les types de requêtes que
+# nous ne voulons pas journaliser
+SetEnvIf Request_Method "GET" ne_pas_journaliser
+SetEnvIf Request_Method "PROPFIND" ne_pas_journaliser
+
+# Désactiver "ne_pas_journaliser" pour les URL Subversion qui ne sont pas privées.
+SetEnvIf dans_depot 0 !ne_pas_journaliser
+
+# Journaliser la requête, seulement si "ne_pas_journaliser" n'est pas activée
+CustomLog logs/access_log env=!ne_pas_journaliser
+</programlisting>
</informalexample>
+<!--
<para>Using this configuration, <command>httpd</command> would
still log <literal>GET</literal> requests aimed at public
Subversion URLs. These are the sorts of requests generated
@@ -6498,13 +6547,29 @@
"private" Subversion URLs—which are the very sorts of
requests used to fetch each and every individual file during
a checkout operation—won't get logged.</para>
+-->
+ <para>En utilisant cette configuration,<command>httpd</command>
+ journalisera toujours les requêtes <literal>GET</literal> qui
+ pointent vers des URL Subversion publiques. Ce sont les types
+ de requêtes émises par les navigateurs Web lorsqu'un
+ utilisateur navigue dans le dépôt directement. Mais les
+ requêtes <literal>GET</literal> et <literal>PROPFIND</literal>
+ qui pointent vers des URL Subversion dites
+ <quote>privées</quote> (ce sont les types de requêtes
+ utilisées pour passer en revue individuellement chacun des
+ fichiers lors d'une opération d'extraction) ne seront pas
+ journalisées.</para>
</sect3>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<sect3 id="svn.serverconfig.httpd.extra.writethruproxy">
+<!--
<title>Write-through proxying</title>
+-->
+ <title>Mandataire en écriture</title>
+<!--
<para>
<indexterm>
<primary>WebDAV</primary>
@@ -6539,20 +6604,75 @@
then automatically <quote>pushes</quote> the new revision to
each slave server using the <command>svnsync</command>
replication tool.</para>
+-->
+ <para>
+ <indexterm>
+ <primary>WebDAV</primary>
+ <secondary>mandataire</secondary>
+ <see>httpd, mandataire en écriture</see>
+ </indexterm>
+ <indexterm>
+ <primary>httpd</primary>
+ <secondary>mandataire en écriture</secondary>
+ <tertiary>maître</tertiary>
+ </indexterm>
+ <indexterm>
+ <primary>httpd</primary>
+ <secondary>mandataire en écriture</secondary>
+ <tertiary>esclave</tertiary>
+ </indexterm>Un des avantages notables d'Apache comme serveur
+ Subversion est qu'il peut être configuré pour effectuer de la
+ réplication. Par exemple, imaginez que votre équipe soit
+ répartie sur quatre sites dans différents coins du globe. Le
+ dépôt Subversion ne peut exister que sur un de ces sites, ce
+ qui signifie que les trois autres sites n'auront pas un accès
+ très satisfaisant — ils devront sans doute faire avec
+ un trafic plus lent et des temps de réponse plus longs lors
+ des mises à jour et des propagations. Une solution très
+ puissante est de mettre en place un système constitué d'un
+ serveur Apache <firstterm>maître</firstterm> et de
+ plusieurs serveurs
+ Apache <firstterm>esclaves</firstterm>. Si vous
+ placez un serveur esclave sur chacun des sites, les
+ utilisateurs peuvent extraire une copie de travail de
+ l'esclave qui est le plus proche d'eux. Toutes les requêtes
+ de lecture vont au serveur esclave local. Les requêtes
+ d'écriture sont automatiquement routées vers l'unique
+ serveur maître. Lorsque la propagation se termine, le maître
+ <quote>pousse</quote> la nouvelle révision vers chaque serveur
+ esclave en utilisant l'outil de réplication
+ <command>svnsync</command>.</para>
+<!--
<para>This configuration creates a huge perceptual speed
increase for your users, because Subversion client traffic
is typically 80–90% read requests. And if those
requests are coming from a <emphasis>local</emphasis>
server, it's a huge win.</para>
+-->
+ <para>Cette configuration permet une immense amélioration de la
+ vitesse perçue par les utilisateurs, car le trafic d'un client
+ Subversion est généralement constitué à
+ 80 - 90 % de requêtes de lecture. Et ces
+ requêtes étant traitées par un serveur
+ <emphasis>local</emphasis>, le gain est énorme.</para>
+<!--
<para>In this section, we'll walk you through a standard setup
of this single-master/multiple-slave system. However, keep
in mind that your servers must be running at least Apache
2.2.0 (with <command>mod_proxy</command> loaded) and
Subversion 1.5 (<command>mod_dav_svn</command>).</para>
+-->
+ <para>Dans cette section, nous vous accompagnons dans la mise en
+ place standard de ce système comportant un maître unique et
+ plusieurs esclaves. Cependant, gardez à l'esprit que vos
+ serveurs doivent faire tourner au moins Apache 2.2.0
+ (avec le module <command>mod_proxy</command> chargé) et
+ Subversion 1.5 (<command>mod_dav_svn</command>).</para>
<note>
+<!--
<para>Ours is just one example of how you might setup a
Subversion write-through proxy configuration. There are
other approaches. For example, rather than having the
@@ -6565,11 +6685,30 @@
of what happens in a Subversion WebDAV proxy deployment
scenario, and then implement the specific approach that
works best for their organization.</para>
+-->
+ <para>Ceci est juste un exemple de la façon dont vous pouvez
+ configurer un serveur mandataire Subversion. Il existe
+ d'autres approches. Par exemple, plutôt que d'avoir un
+ serveur maître qui pousse les modifications vers chaque
+ serveur esclave, les esclaves pourraient aller chercher
+ ces modifications périodiquement sur le serveur maître. Ou
+ bien le serveur pourrait pousser les modifications vers un
+ seul serveur esclave, charge à ce serveur esclave de les
+ pousser vers un autre serveur esclave et ainsi de suite pour
+ atteindre tous les serveurs esclaves. Nous conseillons aux
+ administrateurs d'utiliser cette section comme point de
+ départ pour comprendre les bases d'un déploiement d'un
+ serveur mandataire WebDAV Subversion, puis d'implémenter
+ l'approche qui convient le mieux à leur organisation.</para>
</note>
<sect4 id="svn.serverconfig.httpd.extra.writethruproxy.configure">
+<!--
<title>Configure the servers</title>
+-->
+ <title>Configuration des serveurs</title>
+<!--
<para>First, configure your master server's
<filename>httpd.conf</filename> file in the usual way.
Make the repository available at a certain URI location,
@@ -6578,8 +6717,19 @@
<quote>slave</quote> servers in the exact same way, but
add the special <literal>SVNMasterURI</literal> directive
to the block:</para>
+-->
+ <para>Pour commencer, configurez le fichier
+ <filename>httpd.conf</filename> de votre serveur maître de
+ la façon habituelle. Mettez le dépôt à disposition à un
+ certain emplacement URI et configurez l'authentification
+ ainsi que le contrôle d'accès comme vous le souhaitez. Une
+ fois que c'est fait, configurez chacun de vos serveurs
+ <quote>esclaves</quote> exactement de la même manière, mais
+ ajoutez la directive <literal>SVNMasterURI</literal> au
+ bloc :</para>
<informalexample>
+<!--
<programlisting>
<Location /svn>
DAV svn
@@ -6588,8 +6738,19 @@
…
</Location>
</programlisting>
+-->
+ <programlisting>
+<Location /svn>
+ DAV svn
+ SVNPath /var/svn/depot
+ SVNMasterURI http://maitre.exemple.com/svn
+ …
+</Location>
+</programlisting>
+
</informalexample>
+<!--
<para>This new directive tells a slave server to redirect
all write requests to the master. (This is done
automatically via Apache's <command>mod_proxy</command>
@@ -6598,7 +6759,19 @@
slave servers all have matching authentication and
authorization configurations; if they fall out of sync,
it can lead to big headaches.</para>
+-->
+ <para>Cette nouvelle directive indique à un serveur esclave de
+ rediriger toutes les requêtes d'écriture vers le maître (ce
+ qui est accompli automatiquement par le module
+ <command>mod_proxy</command> d'Apache). Les requêtes
+ ordinaires de lecture, cependant, sont toujours traitées par
+ les esclaves. Assurez-vous que vos serveurs maître et
+ esclaves ont tous des configurations identiques
+ d'authentification et de contrôle d'accès ; En cas de
+ problème de synchronisation, cela peut vous amener à vous
+ arracher les cheveux.</para>
+<!--
<para>Next, we need to deal with the problem of infinite
recursion. With the current configuration, imagine what
will happen when a Subversion client performs a commit to
@@ -6609,15 +6782,39 @@
Subversion client performing a commit, the slave will
immediately attempt to proxy the incoming write request
back to the master! Hilarity ensues.</para>
+-->
+ <para>Ensuite nous devons nous occuper du problème de la
+ récursion infinie. Avec la configuration actuelle, imaginez
+ ce qui se va se passer quand un client Subversion va
+ effectuer une propagation vers le serveur maître. Une fois
+ la propagation terminée, le serveur utilise
+ <command>svnsync</command> pour répliquer la nouvelle
+ révision vers chaque esclave. Mais comme
+ <command>svnsync</command> ne se présente que comme un
+ simple client en train d'effectuer une propagation,
+ l'esclave va immédiatement tenter d'envoyer vers le maître
+ la requête d'écriture qui vient d'arriver ! Et là,
+ patatras !</para>
+<!--
<para>The solution to this problem is to have the master
push revisions to a different
<literal><Location></literal> on the slaves. This
location is configured to <emphasis>not</emphasis> proxy
write requests at all, but to accept normal commits from
(and only from) the master's IP address:</para>
+-->
+ <para>La solution consiste à s'arranger pour que le maître
+ pousse les révisions vers un emplacement
+ <literal><Location></literal> distinct au sein des
+ dépôts esclaves. Cet emplacement est configuré
+ <emphasis>non pas pour servir de mandataire</emphasis> pour
+ les requêtes d'écriture mais pour accepter les propagations
+ normales en provenance de l'adresse IP du maître (et
+ seulement de lui) :</para>
<informalexample>
+<!--
<programlisting>
<Location /svn-proxy-sync>
DAV svn
@@ -6629,13 +6826,29 @@
…
</Location>
</programlisting>
+-->
+ <programlisting>
+<Location /svn-proxy-sync>
+ DAV svn
+ SVNPath /var/svn/depot
+ Order deny,allow
+ Deny from all
+ # Ne laisse que le serveur ayant l'adresse indiquée accéder à cet emplacement :
+ Allow from 10.20.30.40
+ …
+</Location>
+</programlisting>
</informalexample>
</sect4>
<sect4 id="svn.serverconfig.httpd.extra.writethruproxy.replicate">
+<!--
<title>Set up replication</title>
+-->
+ <title>Mise en place de la réplication</title>
+<!--
<para>Now that you've configured
your <literal>Location</literal> blocks on master and
slaves, you need to configure the master to replicate to
@@ -6643,7 +6856,17 @@
which is covered in more detail in
<xref linkend="svn.reposadmin.maint.replication.svnsync"
/>.</para>
+-->
+ <para>Une fois que vous avez configuré les blocs
+ <literal>Location</literal> du maître et des esclaves, vous
+ devez configurer le maître pour que la réplication vers les
+ esclaves fonctionne. Ceci se fait de la manière habituelle,
+ en utilisant <command>svnsync</command>. Si vous n'êtes pas
+ familier avec cet outil, reportez-vous à <xref
+ linkend="svn.reposadmin.maint.replication.svnsync"/> pour
+ plus de détails.</para>
+<!--
<para>First, make sure that each slave repository has a
<filename>pre-revprop-change</filename> hook script which
allows remote revision property changes. (This is
@@ -6652,8 +6875,20 @@
server and configure each of the slave repository URIs to
receive data from the master repository on the local
disk:</para>
+-->
+ <para>Tout d'abord, assurez-vous que chaque dépôt esclave
+ possède une procédure automatique
+ <filename>pre-revprop-change</filename> qui autorise les
+ modifications de propriétés de révisions à distance (cette
+ étape fait partie de la procédure standard pour un serveur
+ qui reçoit les révisions de <command>svnsync</command>).
+ Ensuite, connectez-vous au serveur maître et configurez
+ l'URI de chaque dépôt esclave pour qu'il reçoive les données
+ en provenance du dépôt maître sur le disque
+ local :</para>
<informalexample>
+<!--
<screen>
$ svnsync init http://slave1.example.com/svn-proxy-sync \
file:///var/svn/repos
@@ -6696,14 +6931,66 @@
Committed revision 2.
Copied properties for revision 2.
…
+</screen>-->
+ <screen>
+$ svnsync init http://esclave1.exemple.com/svn-proxy-sync \
+ file://var/svn/depot
+Propriétés copiées pour la révision 0.
+$ svnsync init http://esclave2.exemple.com/svn-proxy-sync \
+ file://var/svn/depot
+Propriétés copiées pour la révision 0.
+$ svnsync init http://esclave3.exemple.com/svn-proxy-sync \
+ file://var/svn/depot
+Propriétés copiées pour la révision 0.
+
+# Effectue la réplication initiale
+
+$ svnsync sync http://esclave1.exemple.com/svn-proxy-sync \
+ file://var/svn/depot
+Transmission des données ........................................
+Révision 1 propagée.
+Propriétés copiées pour la révision 1.
+Transmission des données ..
+Révision 2 propagée.
+Propriétés copiées pour la révision 2.
+…
+
+$ svnsync sync http://esclave2.exemple.com/svn-proxy-sync \
+ file://var/svn/depot
+Transmission des données ........................................
+Révision 1 propagée.
+Propriétés copiées pour la révision 1.
+Transmission des données ..
+Révision 2 propagée.
+Propriétés copiées pour la révision 2.
+…
+
+$ svnsync sync http://esclave3.exemple.com/svn-proxy-sync \
+ file://var/svn/depot
+Transmission des données ........................................
+Révision 1 propagée.
+Propriétés copiées pour la révision 1.
+Transmission des données ..
+Révision 2 propagée.
+Propriétés copiées pour la révision 2.
+…
</screen>
+
</informalexample>
+<!--
<para>After this is done, we configure the master server's
<literal>post-commit</literal> hook script to invoke
<command>svnsync</command> on each slave server:</para>
+-->
+ <para>Une fois ceci fait, nous configurons la procédure
+ automatique post-propagation
+ (<literal>post-commit</literal>) du serveur maître pour
+ qu'elle lance <command>svnsync</command> sur chaque serveur
+ esclave :</para>
<informalexample>
+<!--
<programlisting>
#!/bin/sh
# Post-commit script to replicate newly committed revision to slaves
@@ -6715,8 +7002,22 @@
svnsync sync http://slave3.example.com/svn-proxy-sync \
file:///var/svn/repos > /dev/null 2>&1 &
</programlisting>
+-->
+ <programlisting>
+#!/bin/sh
+# Procédure post-propagation pour répliquer les révisions
+# nouvellement propagées vers les esclaves
+
+svnsync sync http://esclave1.exemple.com/svn-proxy-sync \
+ file:///var/svn/depot > /dev/null 2>&1 &
+svnsync sync http://esclave2.exemple.com/svn-proxy-sync \
+ file:///var/svn/depot > /dev/null 2>&1 &
+svnsync sync http://esclave3.exemple.com/svn-proxy-sync \
+ file:///var/svn/depot > /dev/null 2>&1 &
+</programlisting>
</informalexample>
+<!--
<para>The extra bits on the end of each line aren't
necessary, but they're a sneaky way to allow the sync
commands to run in the background so that the Subversion
@@ -6726,8 +7027,23 @@
<literal>post-revprop-change</literal> hook as well so
that when a user, say, modifies a log message, the slave
servers get that change also:</para>
+-->
+ <para>Les symboles en plus à la fin de chaque ligne ne sont
+ pas nécessaires, mais constituent un moyen astucieux
+ d'autoriser <command>svnsync</command> à lancer des
+ commandes qui fonctionneront à l'arrière-plan, de telle
+ sorte que le client Subversion ne se retrouvera pas à
+ attendre indéfiniment que la propagation se termine. En
+ plus de cette procédure post-propagation
+ (<literal>post-commit</literal>), vous aurez également
+ besoin d'une procédure automatique
+ <literal>post-revprop-change</literal> pour que, disons,
+ quand un utilisateur modifie un message de propagation, les
+ serveurs esclaves reçoivent aussi cette
+ modification :</para>
<informalexample>
+<!--
<programlisting>
#!/bin/sh
# Post-revprop-change script to replicate revprop-changes to slaves
@@ -6743,8 +7059,26 @@
file:///var/svn/repos \
-r ${REV} > /dev/null 2>&1 &
</programlisting>
+-->
+ <programlisting>
+#!/bin/sh
+# Procédure post-revprop-change pour répliquer les modifications
+# des propriétés de révisions vers les esclaves
+
+REV=${2}
+svnsync copy-revprops http://esclave1.exemple.com/svn-proxy-sync \
+ file:///var/svn/depot \
+ -r ${REV} > /dev/null 2>&1 &
+svnsync copy-revprops http://esclave2.exemple.com/svn-proxy-sync \
+ file:///var/svn/depot \
+ -r ${REV} > /dev/null 2>&1 &
+svnsync copy-revprops http://esclave3.exemple.com/svn-proxy-sync \
+ file:///var/svn/depot \
+ -r ${REV} > /dev/null 2>&1 &
+</programlisting>
</informalexample>
+<!--
<para>The only thing we've left out here is what to do about
user-level locks (of the <command>svn lock</command>
variety). Locks are enforced by the master server during
@@ -6763,12 +7097,39 @@
may be a nonissue for you. Sadly, for those teams which
do use locks, we have no recommendations on how to
gracefully work around this shortcoming.</para>
+-->
+ <para>La seule chose que nous n'avons pas abordé concerne
+ les verrous (ceux de la commande <command>svn
+ lock</command>). Comme ces verrous sont gérés strictement
+ par le serveur maître au moment des propagations ; mais
+ toutes les informations relatives aux verrous sont
+ distribuées au moment des opérations de lectures telles que
+ <command>svn update</command>et <command>svn
+ status</command> par le serveur esclave. Ainsi, la
+ configuration complète maître/esclaves se doit de répliquer
+ les informations de verrouillage du maître vers les
+ esclaves. Malheureusement, la plupart des mécanismes qui
+ sont utilisés pour effectuer cette réplication sont
+ confrontés à un problème à un moment ou à un autre<footnote>
+ <para><ulink
+ url="http://subversion.tigris.org/issues/show_bug.cgi?id=3457"
+ /> suit ces problèmes.</para>
+ </footnote>. De nombreuses équipes n'utilisent pas du tout
+ les fonctionnalités de verrouillage de Subversion, il s'agit
+ donc peut-être pour vous d'un faux problème. Pour ceux qui
+ utilisent les verrous, nous n'avons malheureusement pas de
+ solution simple et universelle pour combler cette
+ lacune.</para>
</sect4>
<sect4 id="svn.serverconfig.httpd.extra.writethruproxy.caveats">
+<!--
<title>Caveats</title>
+-->
+ <title>Pièges à éviter</title>
+<!--
<para>Your master/slave replication system should now be
ready to use. A couple of words of warning are in order,
however. Remember that this replication isn't entirely
@@ -6787,7 +7148,30 @@
out-of-band monitoring to notice synchronization failures
and force <command>svnsync</command> to run when things go
wrong.</para>
+-->
+ <para>Votre système de réplication maître/esclave doit à
+ présent être prêt à l'emploi. Cependant, quelques consignes
+ de prudence sont de mise. Souvenez-vous que la réplication
+ n'est pas totalement robuste en ce qui concerne les
+ plantages machine ou réseau. Par exemple, si l'une des
+ commandes <command>svnsync</command> automatisées demeure
+ inachevée, pour quelque raison que ce soit, les esclaves
+ vont commencer à être décalés. Par exemple, vos utilisateurs
+ distants verront qu'ils ont propagé la révision 100,
+ mais quand ils exécuteront <command>svn update</command>,
+ leur serveur local leur indiquera que la révision 100
+ n'existe pas encore ! Bien sûr, le problème se réglera
+ automatiquement dès qu'une autre propagation aura lieu et
+ que la commande <command>svnsync</command> qui s'ensuit aura
+ fonctionné — cette synchronisation répliquera toutes
+ les révisions en attente. Néanmoins, vous pouvez décider de
+ mettre en place une surveillance des décalages, vérifiant le
+ bon fonctionnement de la synchronisation et qui, en cas de
+ problème, déclenche une nouvelle exécution de
+ <command>svnsync</command>.</para>
+
+<!--
<para>Another limitation of the write-through proxy
deployment model involves version mismatches—of the
version of Subversion which is installed, that
@@ -6812,16 +7196,49 @@
Subversion <literal><Location></literal> block with
the <literal>SVNAdvertiseV2Protocol Off</literal>
directive.</para>
+-->
+ <para>Une autre limitation de modèle de déploiement avec
+ mandataires concerne ceux qui ont des versions différentes
+ de Subversion installées sur les différents maîtres et
+ esclaves. Chaque nouvelle version de Subversion peut (et
+ c'est souvent le cas) ajouter des nouvelles fonctionnalités
+ au protocole réseau utilisé entre le serveur et les clients.
+ Comme la négociation des fonctionnalités possibles
+ intervient à la connexion au serveur esclave, ce sont les
+ capacités annoncées par le serveur esclaves qui sont
+ utilisées. Mais les opérations d'écriture sont transmises au
+ serveur maître pratiquement littéralement. En conséquence,
+ il existe toujours un risque que le serveur esclave négocie
+ avec le client l'utilisation de fonctionnalités qui sont
+ possibles avec l'esclave mais que le serveur maître ne
+ comprenne pas parce qu'il fait tourner une version plus
+ ancienne de Subversion. Nous avons recensé deux problèmes
+ de ce type avec Subversion 1.7, qui a modifié sensiblement
+ son protocole HTTP. Si vous déployez un serveur esclave en
+ version 1.7 et que votre serveur maître utilise une version
+ antérieure, vous devez configurer votre serveur esclave avec
+ la directive <literal>SVNAdvertiseV2Protocol Off</literal>
+ dans votre bloc <literal><Location></literal>.</para>
<tip>
+<!--
<para>For the best results possible, try to run the same
version of Subversion on your master and slave
servers.</para>
+-->
+ <para>Pour obtenir le meilleur fonctionnement possible,
+ essayez de faire tourner la même version de Subversion sur
+ le maître et sur les esclaves.</para>
</tip>
<sidebar>
+<!--
<title>Can We Set Up Replication with svnserve?</title>
+-->
+ <title>Pouvons-nous mettre en place la réplication avec
+ svnserve ?</title>
+<!--
<para>If you're using <command>svnserve</command> instead
of Apache as your server, you can certainly configure
your repository's hook scripts to invoke
@@ -6839,13 +7256,39 @@
proxying system.</para>
</sidebar>
+-->
+ <para>Si vous utilisez <command>svnserve</command> au lieu
+ d'Apache comme serveur, vous pouvez tout à fait configurer
+ les procédures automatiques de votre dépôt pour qu'elles
+ lancent <command>svnsync</command> comme nous l'avons
+ expliqué ici, lançant ainsi la réplication automatique du
+ maître vers les esclaves. Malheureusement, à l'heure où
+ nous écrivons ces lignes, il n'y a pas moyen de s'assurer
+ que des serveurs esclaves <command>svnserve</command>
+ envoient automatiquement les requêtes d'écriture vers le
+ serveur maître. Cela veut dire que vos utilisateurs ne
+ pourraient extraire que des copies de travail en lecture
+ seule des serveurs esclaves. Il vous faudrait donc
+ configurer vos serveurs esclaves pour qu'ils refusent
+ complètement tout accès en écriture. Cela peut être utile
+ pour créer des <quote>miroirs</quote> en lecture seule de
+ projets open source populaires, mais il ne s'agit alors
+ plus d'un système de mandataire d'écriture
+ transparent.</para>
+
+ </sidebar>
+
</sect4>
</sect3>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<sect3 id="svn.serverconfig.httpd.extra.other">
+<!--
<title>Other Apache features</title>
+-->
+ <title>Autres fonctionnalités d'Apache</title>
+<!--
<para>Several of the features already provided by Apache in
its role as a robust web server can be leveraged for
increased functionality or security in Subversion as well.
@@ -6855,6 +7298,19 @@
using <literal>https://</literal> and enjoy a high-quality
encrypted network session.</para>
+-->
+ <para>Il y a également plusieurs fonctionnalités fournies par
+ Apache, en tant que serveur web robuste, dont on peut tirer
+ profit pour améliorer les fonctionnalités ou la sécurité de
+ Subversion. Le client Subversion est capable d'utiliser SSL
+ (Secure Socket Layer, le protocole de sécurisation des
+ échanges sur internet, présenté auparavant). Si votre client
+ Subversion a été compilé en incluant le support de SSL, il
+ peut accéder à votre serveur Apache en utilisant des URL
+ <literal>https://</literal> et bénéficier d'une session réseau
+ avec un chiffrement de grande qualité.</para>
+
+<!--
<para>Equally useful are other features of the Apache and
Subversion relationship, such as the ability to specify a
custom port (instead of the default HTTP port 80) or a
@@ -6862,6 +7318,16 @@
should be accessed, or the ability to access the repository
through an HTTP proxy.</para>
+-->
+ <para>D'autres fonctionnalités de la relation Apache/Subversion
+ sont également tout aussi utiles, comme par exemple la
+ possibilité de spécifier un port personnalisé (au lieu du port
+ HTTP par défaut, 80) ou un nom de domaine virtuel par lequel
+ accéder au dépôt Subversion ou encore la possibilité d'accéder
+ au dépôt <foreignphrase>via</foreignphrase> un serveur
+ mandataire HTTP.</para>
+
+<!--
<para>Finally, because <command>mod_dav_svn</command> is
speaking a subset of the WebDAV/DeltaV protocol, it's
possible to access the repository via third-party DAV
@@ -6871,6 +7337,18 @@
complicated topic, but also wondrous when implemented. For
details, read <xref linkend="svn.webdav"/>.</para>
+-->
+ <para>Enfin, comme <command>mod_dav_svn</command> se sert d'un
+ sous-ensemble du protocole WebDAV/DeltaV pour communiquer, il
+ est possible d'accéder au dépôt depuis des clients DAV tiers.
+ La possibilité de monter un serveur DAV en tant que
+ <quote>dossier partagé</quote> réseau standard est intégrée
+ dans la plupart des systèmes d'exploitation modernes (Win32,
+ OS X et Linux). C'est un sujet compliqué, mais merveilleux
+ une fois mis en place. Pour plus de détails, consultez l'<xref
+ linkend="svn.webdav"/>.</para>
+
+<!--
<para>Note that there are a number of other small tweaks one
can make to <command>mod_dav_svn</command> that perhaps do
not merit extensive coverage. For those interested,
@@ -6879,6 +7357,15 @@
to which <command>mod_dav_svn</command> responds in
<xref linkend="svn.serverconfig.httpd.ref.mod_dav_svn"
/>.</para>
+-->
+ <para>Notez qu'il y a un certain nombre d'autres petits
+ <quote>bricolages</quote> que l'on peut faire autour de
+ <command>mod_dav_svn</command> qui sont trop obscurs pour être
+ mentionnés dans ce chapitre. Pour voir la liste complète de
+ toutes les directives <filename>httpd.conf</filename>
+ auxquelles <command>mod_dav_svn</command> obéit, reportez-vous
+ à <xref linkend="svn.serverconfig.httpd.ref.mod_dav_svn"
+ />.</para>
</sect3>
</sect2>
More information about the svnbook-dev
mailing list