[svnbook] r4846 committed - Translation: Caveats

[svnbook at googlecode.com]

Revision: 4846
Author:   jmfelderhoff at gmx.eu
Date:     Tue Jul  1 20:01:46 2014 UTC
Log:      Translation: Caveats

http://code.google.com/p/svnbook/source/detail?r=4846

Modified:
  /branches/1.7/de/book/ch06-server-configuration.xml

=======================================
--- /branches/1.7/de/book/ch06-server-configuration.xml	Wed Jun 25 05:47:38  
2014 UTC
+++ /branches/1.7/de/book/ch06-server-configuration.xml	Tue Jul  1 20:01:46  
2014 UTC
@@ -6240,6 +6240,72 @@
              hingewiesen zu werden, damit Sie in diesem Fall
              <command>svnsync</command> erneut aufrufen können.</para>

+<!--
+          <para>Another limitation of the write-through proxy
+            deployment model involves version mismatches—of the
+            version of Subversion which is installed, that
+            is—between the master and slave servers.  Each new
+            release of Subversion may (and often does) add new
+            features to the network protocol used between the clients
+            and servers.  Since feature negotiation happens against
+            the slave, it is the slave's protocol version and feature
+            set which is used.  But write operations are passed
+            through to the master server quite literally.  Therefore,
+            there is always a risk that the slave server will answer a
+            feature negotiation request from the client in way that is
+            true for the slave, but untrue for the master if the
+            master is running an older version of Subversion.  This
+            could result in the client trying to use a new feature
+            that the master doesn't understand, and failing.  There
+            are a couple of known problems of this sort in Subversion
+            1.7, which introduced a major revision of its HTTP
+            protocol.  If you are deploying a Subversion 1.7 slave
+            server in front of a pre-1.7 master, you'll want to
+            configure your slave server's
+            Subversion <literal><Location></literal> block with
+            the <literal>SVNAdvertiseV2Protocol Off</literal>
+            directive.</para>
+-->
+          <para>Eine weitere Einschränkung des Modells eines
+            durchreichenden Proxyeinsatzes betrifft nicht
+            übereinstimmende Versionen – und zwar der
+            installierten Subversion-Version – zwischen dem
+            Master und den Slave-Servern. Jede neue Veröffentlichung
+            von Subversion kann dem Netzwerkprotokoll, das zwischen
+            den Clients und den Servern verwendet wird neue
+            Funktionalität hinzufügen (und macht dies auch oftmals).
+            servers. Da die Aushandlung der Funktionalität mit dem
+            Slave erfolgt, wird hier das Protokoll und der
+            Funktionalitätsumfang des Slaves benutzt. Allerdings
+            werden Schreiboperationen ziemlich wörtlich an den
+            Master-Server weitergereicht. Daher besteht immer die
+            Gefahr, dass der Slave-Server eine Funktionalitäts-Anfrage
+            auf eine Art beantwortet, die für den Slave zutrifft, für
+            den Master aber nicht, sofern er eine ältere Version von
+            Subversion betreibt. Das kann dazu führen, dass der
+            Client eine neue Funktionalität verwenden möchte, die der
+            Master nicht versteht, und somit zu einem Fehler. Es
+            existieren einige bekannte Probleme dieser Art in
+            Subversion 1.7, das eine größere Überarbeitung seines
+            HTTP-Protokolls einführte. Falls Sie einen Slave mit
+            Subversion 1.7 vor einem Master mit einer Version vor 1.7
+            betreiben, sollten Sie den Subversion
+            <literal><Location></literal>-Block Ihres
+            Slave-Servers mit der Direktive
+            <literal>SVNAdvertiseV2Protocol Off</literal>
+            konfigurieren.</para>
+
+          <tip>
+<!--
+            <para>For the best results possible, try to run the same
+              version of Subversion on your master and slave
+              servers.</para>
+-->
+            <para>Für ein bestmögliches Ergebnis sollten Sie
+              versuchen, die selbe Version von Subversion auf dem
+              Master- und Slave-Server laufen zu lassen.</para>
+          </tip>
+
            <sidebar>
  <!--
              <title>Can We Set Up Replication with svnserve?</title>