[svnbook] r4846 committed - Translation: Caveats
svnbook at googlecode.com
svnbook at googlecode.com
Tue Jul 1 15:02:01 CDT 2014
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>
More information about the svnbook-dev
mailing list