[svnbook] r4421 committed - Some wording changes. Translated caveats.
svnbook at googlecode.com
svnbook at googlecode.com
Sun Feb 10 16:31:20 CST 2013
Revision: 4421
Author: jmfelderhoff at gmx.eu
Date: Sun Feb 10 14:31:06 2013
Log: Some wording changes. Translated caveats.
http://code.google.com/p/svnbook/source/detail?r=4421
Modified:
/branches/1.5/de/book/ch06-server-configuration.xml
=======================================
--- /branches/1.5/de/book/ch06-server-configuration.xml Sun Dec 30 14:42:02
2012
+++ /branches/1.5/de/book/ch06-server-configuration.xml Sun Feb 10 14:31:06
2013
@@ -285,7 +285,7 @@
<row>
<!-- <entry>Master-slave server replication</entry> -->
- <entry>Master-Slave-Server Replikationen</entry>
+ <entry>Master-Slave-Server Replizierungen</entry>
<!-- <entry>Transparent write-proxying available from slave to
master</entry> -->
<entry>transparenter Schreib-Proxy vom Slave zum
Master</entry>
@@ -872,7 +872,7 @@
den Projektarchiv-Zugriff warnen. Vom Standpunkt der
Sicherheit ist dies effektiv dasselbe wie die Verwendung von
<literal>file://</literal> für den Zugriff durch lokale
- Benutzer und kann zu denselben Problemen führen, wenn der
+ Anwender und kann zu denselben Problemen führen, wenn der
Administrator nicht alle Vorsicht walten lässt.
</para>
</listitem>
@@ -1691,7 +1691,7 @@
</screen>
<para> Der Wert von <literal>password-db</literal> kann den
- absoluten oder relativen Pfad zur Benutzerdatei enthalten.
+ absoluten oder relativen Pfad zur Anwenderdatei enthalten.
In der Regel, ist es am einfachsten diese Datei ebenfalls
im <filename>conf/</filename>-Verzeichnis des
Projektarchivs zu speichern – also dort, wo auch
@@ -1699,14 +1699,14 @@
möchten Sie vielleicht eine Passwortdatei für mehrere
Repositories verwenden; in diesem Fall sollten Sie die
Datei an einem zentraleren Ort ablegen. Die
- Projektarchive, die sich die Benutzerdatei teilen, sollten
+ Projektarchive, die sich die Anwenderdatei teilen, sollten
so konfiguriert sein, dass sie derselben
- Authentifizierungsumgebung angehören, da die Benutzerliste
+ Authentifizierungsumgebung angehören, da die Anwenderliste
im Wesentlichen einen Authentifizierungs-Bereich definiert.
Wo die Datei auch liegen mag, stellen Sie sicher, die Lese-
und Schreibrechte entsprechend zu setzen. Falls Sie wissen,
unter welchem Konto <command>svnserve</command> laufen
- wird, sollten Sie den Lesezugriff zur Benutzerdatei auf das
+ wird, sollten Sie den Lesezugriff zur Anwenderdatei auf das
Notwendige beschränken. </para>
</sect3>
@@ -1761,13 +1761,13 @@
<screen>
[general]
-password-db = Benutzerdatei
+password-db = Anwenderdatei
realm = Ihr realm
-# Anonyme Benutzer können nur lesend zugreifen
+# Anonyme Anwender können nur lesend zugreifen
anon-access = read
-# Authentifizierte Benutzer können sowohl lesen als auch schreiben
+# Authentifizierte Anwender können sowohl lesen als auch schreiben
auth-access = write
</screen>
@@ -1800,13 +1800,13 @@
<screen>
[general]
-password-db = Benutzerdatei
+password-db = Anwenderdatei
realm = Ihr realm
-# Anonyme Benutzer sind nicht erlaubt
+# Anonyme Anwender sind nicht erlaubt
anon-access = none
-# Authentifizierte Benutzer können sowohl lesen als auch schreiben
+# Authentifizierte Anwender können sowohl lesen als auch schreiben
auth-access = write
</screen>
@@ -1844,7 +1844,7 @@
<screen>
[general]
-password-db = Benutzerdatei
+password-db = Anwenderdatei
realm = Ihr realm
# Zum Festlegen von umfangreicheren Zugriffsregeln für bestimmte Bereiche
@@ -2119,11 +2119,11 @@
usernames and passwords in the database:</para>
-->
<para>haben Sie SASL aufgefordert, Clients den DIGEST-MD5
- Mechanismus anzubieten und Benutzerpasswörter mit einer
+ Mechanismus anzubieten und Anwenderpasswörter mit einer
privaten Passwort-Datenbank in
<filename>/etc/my_sasldb</filename> abzugleichen. Ein
Systemadministrator kann dann mit dem Programm
- <command>saslpasswd2</command> Benutzernamen und Passwörter
+ <command>saslpasswd2</command> Anwendernamen und Passwörter
in der Datenbank eintragen oder bearbeiten:</para>
<screen>
@@ -2288,7 +2288,7 @@
praktisch sein, da es die Notwendigkeit echter Systemkonten
vermeidet. Andererseits haben einige Administratoren bereits
etablierte SSH-Authentifizierungs-Frameworks im Einsatz. In
- diesen Fällen haben die Benutzer des Projektes bereits
+ diesen Fällen haben die Anwender des Projektes bereits
Systemkonten, um sich damit über SSH mit dem Server zu
verbinden.</para>
@@ -2334,17 +2334,17 @@
<para>In diesem Beispiel ruft der Subversion-Client einen
lokalen <command>ssh</command>-Prozess auf, der sich mit
<literal>host.example.com</literal> verbindet, sich (gemäß der
- SSH-Benutzerkonfiguration) als Benutzer
+ SSH-Anwenderkonfiguration) als Anwender
<literal>harryssh</literal> authentisiert und dann auf dem
entfernten Rechner einen privaten
- <command>svnserve</command>-Prozess unter der Benutzerkennung
+ <command>svnserve</command>-Prozess unter der Anwenderkennung
<literal>harryssh</literal> startet. Der Befehl
<command>svnserve</command> wird im Tunnelmodus
(<option>-t</option>) aufgerufen und dessen Netzprotokoll wird
über die durch den Tunnelagenten <command>ssh</command>
verschlüsselte Verbindung <quote>getunnelt</quote>. Falls der
Client eine Übergabe macht, wird der authentifizierte
- Benutzername <literal>harryssh</literal> als Autor der neuen
+ Anwendername <literal>harryssh</literal> als Autor der neuen
Revision verwendet.</para>
<!--
@@ -2391,9 +2391,9 @@
gibt (siehe <xref
linkend="svn.serverconfig.netmodel.credcache"/>). Der
Subversion-Client stellt häufig mehrere Verbindungen mit dem
- Projektarchiv her, wenngleich Benutzer das wegen der
+ Projektarchiv her, wenngleich Anwender das wegen der
zwischengespeicherten Passwörter normalerweise gar nicht
- mitbekommen. Jedoch könnten Benutzer bei Verwendung von
+ mitbekommen. Jedoch könnten Anwender bei Verwendung von
<literal>svn+ssh://</literal>-URLs durch die wiederholten
Passwortanfragen für ausgehende Verbindungen von
<command>ssh</command> etwas genervt sein. Die Lösung besteht
@@ -2428,7 +2428,7 @@
größtenteils durch die Betriebssystemberechtigungen auf die
Datenbankdateien des Projektarchivs gesteuert, als ob
Harry direkt über einen <literal>file://</literal>-URL auf das
- Projektarchiv zugreifen würde. Falls mehrere Benutzer direkt
+ Projektarchiv zugreifen würde. Falls mehrere Anwender direkt
auf das Projektarchiv zugreifen sollen, möchten Sie sie
vielleicht in eine gemeinsame Gruppe zusammenfassen; Sie
sollten auch auf umasks achten (lesen Sie auf alle Fälle <xref
@@ -2441,7 +2441,7 @@
<footnote>
<para>Beachten Sie, dass die Verwendung irgendwelcher
durch <command>svnserve</command> sichergestellten
- Zugriffskontrollen sinnlos ist, da der Benutzer ohnehin
+ Zugriffskontrollen sinnlos ist, da der Anwender ohnehin
direkten Zugriff auf die Projektarchiv-Datenbank
hat.</para>
</footnote>
@@ -2499,7 +2499,7 @@
<literal>svn+rsh://host/path</literal>. Bei Verwendung des
neuen URL-Schemas führt der Subversion-Client im Hintergrund
eigentlich den Befehl <userinput>rsh host svnserve
- -t</userinput> aus. Falls Sie einen Benutzernamen im URL
+ -t</userinput> aus. Falls Sie einen Anwendernamen im URL
angeben (z.B.
<literal>svn+rsh://username@host/path</literal>), wird der
Client das auch mit in seinen Befehl übernehmen
@@ -2587,7 +2587,7 @@
Server. In diesem Abschnitt zeigen wir, wie der von
<command>sshd</command> ausgeführte
<command>svnserve</command>-Befehl genau festgelegt wird sowie
- sich mehrere Benutzer ein einzelnes Systemkonto teilen
+ sich mehrere Anwender ein einzelnes Systemkonto teilen
können.</para>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-->
@@ -2610,7 +2610,7 @@
welches Sie zum Starten von <command>svnserve</command>
verwenden möchten. Stellen Sie sicher, dass für das Konto
ein Paar bestehend aus einem öffentlichen und einem privaten
- SSH-Schlüssel installiert ist und dass sich der Benutzer
+ SSH-Schlüssel installiert ist und dass sich der Anwender
über die Authentisierung mit einem öffentlichen Schlüssel
anmelden kann. Die Authentisierung mit Passwort wird nicht
funktionieren, da sich alle folgenden SSH-Tricks um die
@@ -2719,7 +2719,7 @@
Wurzelverzeichnis verankert wird, so wie es oft gemacht
wird, wenn <command>svnserve</command> als Daemon-Prozess
läuft. Das könnte entweder geschehen, um den Zugriff auf
- Teile des Systems einzuschränken oder um dem Benutzer die
+ Teile des Systems einzuschränken oder um dem Anwender die
Bürde abzunehmen, einen absoluten Pfad im URL
<literal>svn+ssh://</literal> angeben zu müssen.</para>
@@ -2733,8 +2733,8 @@
option:</para>
-->
<para>Es besteht weiterhin die Möglichkeit, dass sich mehrere
- Benutzer ein einzelnes Konto teilen. Statt ein gesondertes
- Konto für jeden Benutzer zu erstellen, generieren Sie für
+ Anwender ein einzelnes Konto teilen. Statt ein gesondertes
+ Konto für jeden Anwender zu erstellen, generieren Sie für
jede Person jeweils ein Paar aus einem öffentlichen und
einem privaten Schlüssel. Tragen Sie dann jeden öffentlichen
Schlüssel in eine eigene Zeile der Datei
@@ -2763,7 +2763,7 @@
über einen angepassten Befehl, der ausgeführt wird. Die
Option <option>--tunnel-user</option> teilt
<command>svnserve</command> mit, das benannte Argument als
- den authentifizierten Benutzer zu akzeptieren. Ohne
+ den authentifizierten Anwender zu akzeptieren. Ohne
<option>--tunnel-user</option> sähe es so aus als kämen alle
Übergaben vom gemeinsamen Konto.</para>
@@ -2780,13 +2780,13 @@
after the <literal>command</literal>:</para>
-->
<para>Ein letztes Wort zur Warnung: Die Zugangsberechtigung
- für einen Benutzer über einen öffentlichen Schlüssel und ein
+ für einen Anwender über einen öffentlichen Schlüssel und ein
gemeinsames Konto könnte noch weitere SSH-Zugänge erlauben,
selbst wenn Sie einen Wert für <literal>command</literal> in
in <filename>authorized_keys</filename> angegeben haben. So
- kann der Benutzer beispielsweise Shell-Zugang über SSH
+ kann der Anwender beispielsweise Shell-Zugang über SSH
erlangen oder X11 oder allgemeine Portweiterleitung über
- Ihren Server einrichten. Um Ihrem Benutzer die
+ Ihren Server einrichten. Um Ihrem Anwender die
geringstmögliche Erlaubnis zu erteilen, sollten Sie
unmittelbar nach <literal>command</literal> eine Reihe
einschränkender Optionen angeben:</para>
@@ -3369,7 +3369,7 @@
müssen, die Apache für Sie zur Verfügung stellt, oder dass Sie
die Direktiven <literal>User</literal> und
<literal>Group</literal> in <filename>httpd.conf</filename>
- verwenden, um Apache mit denjenigen Benutzer- und
+ verwenden, um Apache mit denjenigen Anwender- und
Gruppenkennungen laufen zu lassen, die auch das
Subversion-Projektarchiv besitzt. Es gibt keine einzig
richtige Methode, um die Berechtigungen zu vergeben, und jeder
@@ -3487,10 +3487,10 @@
-->
<para>Die einfachste Methode, einen Client zu authentifizieren
geht über den HTTP-Basic-Authentifizierungsmechanismus, der
- einfach einen Benutzernamen und ein Passwort verwendet, um
- sicherzustellen, das ein Benutzer auch derjenige ist, für
+ einfach einen Anwendernamen und ein Passwort verwendet, um
+ sicherzustellen, das ein Anwender auch derjenige ist, für
den er sich ausgibt. Apache stellt ein Dienstprogramm zur
- Verwaltung der Liste zulässiger Benutzernanen und Passwörter
+ Verwaltung der Liste zulässiger Anwendernanen und Passwörter
namens <command>htpasswd</command> zur Verfügung. Lassen Sie
uns Sally und Harry die Berechtigung zur Übergabe erteilen.
Zunächst müssen wir sie der Passwortdatei hinzufügen:</para>
@@ -3551,7 +3551,7 @@
spezifizieren. <literal>AuthName</literal> ist ein
beliebiger Name, den Sie Ihrer Authentifizierungsdomäne
geben. Die meisten Browser zeigen diesen Namen in einem
- Dialog an, wenn der Browser den Benutzer nach seinem Namen
+ Dialog an, wenn der Browser den Anwender nach seinem Namen
und dem Passwort fragt. Verwenden Sie schließlich die
Direktive <literal>AuthUserFile</literal>, um den Ort der
Passwortdatei zu spezifizieren, die sie mit
@@ -3591,7 +3591,7 @@
-->
<para>Dieser <literal><Location></literal>-Block ist
noch unvollständig und bewirkt noch nichts sinnvolles. Er
- teilt Apache lediglich mit, dass es sich den Benutzernamen
+ teilt Apache lediglich mit, dass es sich den Anwendernamen
und das Passwort vom Subversion-Client besorgen soll, falls
eine Autorisierung benötigt wird. Was hier jedoch noch
fehlt, sind Direktiven, die Apache sagen,
@@ -3601,7 +3601,7 @@
Das Einfachste ist es, alle Anfragen zu schützen. Durch
Hinzufügen von <literal>Require valid-user</literal> wird
Apache mitgeteilt, dass alle Anfragen einen
- authentifizierten Benutzer erfordern:</para>
+ authentifizierten Anwender erfordern:</para>
<screen>
<Location /svn>
@@ -3654,12 +3654,12 @@
die Identität des Clients zu bestätigen,
<emphasis>ohne</emphasis> das Passwort als Klartext durch
das Netz zu schicken. Unter der Voraussetzung, dass sowohl
- dem Client als auch dem Server das Passwort des Benutzers
+ dem Client als auch dem Server das Passwort des Anwenders
bekannt ist, können sie verifizieren, dass das Passwort
dasselbe ist, indem sie eine Hashfunktion auf ein
Einweg-Informationshäppchen anwenden. Der Server sendet eine
kleine zufällige Zeichenkette an den Client. Der Client
- verwendet das Passwort des Benutzers, um die Zeichenkette zu
+ verwendet das Passwort des Anwenders, um die Zeichenkette zu
hashen, und der Server prüft dann, ob der gehashte Wert dem
erwarteten Ergebnis entspricht.</para>
@@ -3883,7 +3883,7 @@
Option <literal>(p)</literal>ermanent
auswählen, wird das Server-Zertifikat in Ihrem privaten
Laufzeit-<filename>auth/</filename>-Bereich
- zwischengespeichert, ebenso wie Ihr Benutzername und
+ zwischengespeichert, ebenso wie Ihr Anwendername und
Passwort (siehe <xref
linkend="svn.serverconfig.netmodel.credcache"/>). Falls es
zwischengespeichert ist, wird Subversion diesem Zertifikat
@@ -4334,7 +4334,7 @@
-->
<para>Der einfachste Block besteht aus einem völlig offenen
Zugang. In diesem Szenario schickt Apache niemals
- Aufforderungen zur Authentisierung, so dass alle Benutzer
+ Aufforderungen zur Authentisierung, so dass alle Anwender
als <quote>anonymous</quote> behandelt werden. (Siehe <xref
linkend="svn.serverconfig.httpd.authz.perdir.ex-1"/>.)
</para>
@@ -4416,10 +4416,10 @@
# unsere Zugangsrichtlinie
AuthzSVNAccessFile /path/to/access/file
- # nur authentifizierte Benutzer haben Zugriff auf das Projektarchiv
+ # nur authentifizierte Anwender haben Zugriff auf das Projektarchiv
Require valid-user
- # wie ein Benutzer zu authentifizieren ist
+ # wie ein Anwender zu authentifizieren ist
AuthType Basic
AuthName "Subversion repository"
AuthUserFile /path/to/users/file
@@ -4445,12 +4445,12 @@
Kombination aus authentifizierten und anonymen Zugriff zu
erlauben. So möchten beispielsweise viele Administratoren
den Lesezugriff auf bestimmte Verzeichnisse des
- Projektarchivs für anonyme Benutzer freigeben, während
- in heiklen Bereichen nur authentifizierte Benutzer lesen
+ Projektarchivs für anonyme Anwender freigeben, während
+ in heiklen Bereichen nur authentifizierte Anwender lesen
(oder schreiben) dürfen. Bei dieser Einstellung greifen alle
- Benutzer zunächst anonym auf das Projektarchiv zu. Falls
+ Anwender zunächst anonym auf das Projektarchiv zu. Falls
Ihre Zugangsrichtlinien an einer Stelle einen echten
- Benutzernamen erfordern sollte, fordert Apache den Client
+ Anwendernamen erfordern sollte, fordert Apache den Client
auf, sich zu authentisieren. Eingestellt wird dieses
Verhalten mit den gemeinsam verwendeten Direktiven
<literal>Satisfy Any</literal> sowie <literal>Require
@@ -4499,7 +4499,7 @@
Satisfy Any
Require valid-user
- # wie ein Benutzer zu authentifizieren ist
+ # wie ein Anwender zu authentifizieren ist
AuthType Basic
AuthName "Subversion repository"
AuthUserFile /path/to/users/file
@@ -4848,7 +4848,7 @@
Dateien des Projektarchivs den
<quote>Standard</quote>-MIME-Typen besitzen, normalerweise
<literal>text/plain</literal>. Das kann jedoch
- frustrierend sein, wenn ein Benutzer möchte, dass Dateien
+ frustrierend sein, wenn ein Anwender möchte, dass Dateien
aus dem Projektarchiv etwas aussagekräftiger dargestellt
werden; beispielsweise wäre es nett, wenn eine Datei
<filename>foo.html</filename> aus dem Projektarchiv auch
@@ -5017,7 +5017,7 @@
be a security problem, so this feature is turned off by
default.</para>
-->
- <para>Falls ein Benutzer nun mit dem Web-Browser auf den URL
+ <para>Falls ein Anwender nun mit dem Web-Browser auf den URL
<literal>http://host.example.com/svn/</literal> geht,
sieht er eine Liste aller Projektarchive unterhalb von
<filename>/var/svn</filename>. Offensichtlich kann dies
@@ -5079,7 +5079,7 @@
jede von Apache empfangene eingehende HTTP-Abfrage. Das
macht es einfach, festzustellen, von welchen IP-Adressen
Subversion-Clients kommen, wie oft bestimmte Clients den
- Server benutzen, welche Benutzer sich richtig anmelden und
+ Server benutzen, welche Anwender sich richtig anmelden und
welche Abfragen erfolgreich sind oder fehlschlagen.</para>
<!--
@@ -5163,7 +5163,7 @@
standardmäßigen Verzeichnis für Apache Protokolldateien,
<filename>logs</filename>, anzulegen. Die Variablen
<literal>%t</literal> und <literal>%u</literal> werden
- durch die Zeit bzw. den Benutzernamen der Anfrage ersetzt.
+ durch die Zeit bzw. den Anwendernamen der Anfrage ersetzt.
Die wirklich wichtigen Teile sind die zwei Instanzen von
<literal>SVN-ACTION</literal>. Wenn Apache diese Variable
sieht, ersetzt er den Wert der Umgebungsvariablen
@@ -5253,7 +5253,7 @@
<firstterm>Master</firstterm>-Apache-Server und mehreren
<firstterm>Slave</firstterm>-Apache-Servern besteht. Falls
Sie an jedem Standort einen Slave-Server aufstellen, können
- die Benutzer eine Arbeitskopie vom nächstgelegenen Slave
+ die Anwender eine Arbeitskopie vom nächstgelegenen Slave
auschecken. Alle Leseanfragen gehen an den Server vor Ort.
Schreibanfragen werden automatisch an den einzigen
Master-Server weitergeleitet. Wenn die Übergabe
@@ -5270,7 +5270,7 @@
server, it's a huge win.</para>
-->
<para>Diese Konfiguration bewirkt eine riesige, für Ihre
- Benutzer deutlich wahrnehmbare Geschwindigkeitszunahme, da
+ Anwender deutlich wahrnehmbare Geschwindigkeitszunahme, da
der Netzverkehr von Subversion-Clients normalerweise zu
80—90% aus Leseabfragen besteht. Und wenn diese
Abfragen von einem <emphasis>lokalen</emphasis> Server
@@ -5573,7 +5573,7 @@
der Übergabe warten muss. Zusätzlich zu diesem
<literal>post-commit</literal>-Hook werden Sie außerdem
einen <literal>post-revprop-change</literal>-Hook
- benötigen, damit, wenn ein Benutzer beispielsweise eine
+ benötigen, damit, wenn ein Anwender beispielsweise eine
Protokollnachricht verändert, die Slave-Server diese
Änderung ebenfalls mitbekommen:</para>
@@ -5638,8 +5638,11 @@
</sect4>
<sect4 id="svn.serverconfig.httpd.extra.writethruproxy.caveats">
+<!--
<title>Caveats</title>
-
+-->
+ <title>Warnungen</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
@@ -5658,10 +5661,35 @@
out-of-band monitoring to notice synchronization failures
and force <command>svnsync</command> to run when things go
wrong.</para>
+-->
+
+ <para>Nun sollte Ihr Master-Slave-Replizierungssystem
+ einsatzbereit sein. An dieser Stelle sind einige Worte zur
+ Warnung angebracht. Bedenken Sie, dass diese Replizierung
+ nicht vollständig robust gegenüber Rechner- und
+ Netzwerkausfällen ist. Wenn beispielsweise einer der
+ automatisierten <command>svnsync</command>-Befehle aus
+ irgendeinem Grund nicht vollständig abgeschlossen wird,
+ beginnen die Slaves, hinterher zu hinken. Ihre entfernten
+ Anwender werden sehen, dass sie Revision 100 übergeben
+ haben; wenn sie allerdings <command>svn update</command>
+ aufrufen, wird ihr lokaler Server ihnen mitteilen, dass
+ Revision 100 noch nicht existiert! Natürlich wird das
+ Problem automatisch mit der nächsten Übergabe behoben wenn
+ das folgende <command>svnsync</command> erfolgreich ist
+ – alle wartenden Revisionen werden dann repliziert.
+ Trotzdem möchten Sie vielleicht eine zusätzliche
+ Überwachung einrichten, um auf Synchronisierungsfehler
+ hingewiesen zu werden, damit Sie in diesem Fall
+ <command>svnsync</command> erneut aufrufen können.</para>
<sidebar>
+<!--
<title>Can We Set Up Replication with svnserve?</title>
+-->
+ <title>Können wir eine Replizierung mit svnserve
aufsetzen?</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
@@ -5678,6 +5706,26 @@
open source projects, but it's not a transparent
proxying system.</para> </sidebar>
+-->
+ <para>Falls Sie <command>svnserve</command> statt Apache
+ als Server verwenden, können Sie sicherlich die
+ Hook-Skripte Ihres Projektarchivs dergestalt
+ konfigurieren, dass sie <command>svnsync</command> wie
+ hier gezeigt aufrufen und somit eine Replizierung vom
+ Master zu den Slaves bewirken. Leider besteht zum
+ gegenwärtigen Zeitpunkt nicht die Möglichkeit,
+ Slave-<command>svnserve</command>-Server dazu zu
+ veranlassen, Schreibanfragen automatisch an den Master
+ weiterzuleiten. Das bedeutet, dass Ihre Anwender nur
+ Lesekopien von den Slave-Servern auschecken können. Sie
+ müssten Ihre Slave-Server so konfigurieren, dass sie
+ Schreibanfragen vollständig verbieten. Das könnte für
+ die Bereitstellung von <quote>Spiegeln</quote> mit
+ Lesezugriff beliebter Open-Source-Projekte nützlich
+ sein, jedoch stellt es kein transparentes Proxy-System
+ dar.</para>
+ </sidebar>
+
</sect4>
</sect3>
More information about the svnbook-dev
mailing list