[svnbook] r4026 committed - Finish issue #47 ("1.7: document SVNAdvertiseV2Protocol mod_dav_svn...
svnbook at googlecode.com
svnbook at googlecode.com
Fri Aug 19 12:43:43 CDT 2011
Revision: 4026
Author: cmpilato at gmail.com
Date: Fri Aug 19 10:43:07 2011
Log: Finish issue #47 ("1.7: document SVNAdvertiseV2Protocol
mod_dav_svn
directive"), and then some.
* en/book/ch09-reference.xml
Document mod_dav_svn's new directives:
SVNAdvertiseV2Protocol
SVNCacheFullTexts
SVNCacheTextDeltas
SVNCompressionLevel
SVNInMemoryCacheSize
* en/book/ch06-server-configuration.xml
(svn.serverconfig.httpd.extra.writethruproxy.caveats): Note the
general problem that could occur with version mismatches in
write-through proxy situations, and mentioned
SVNAdvertiseV2Protocol. (NOTE: I think there is still another
problem with revprop atomicity that is not so easily worked
around.)
http://code.google.com/p/svnbook/source/detail?r=4026
Modified:
/trunk/en/book/ch06-server-configuration.xml
/trunk/en/book/ch09-reference.xml
=======================================
--- /trunk/en/book/ch06-server-configuration.xml Thu Aug 18 14:22:26 2011
+++ /trunk/en/book/ch06-server-configuration.xml Fri Aug 19 10:43:07 2011
@@ -3176,6 +3176,37 @@
and force <command>svnsync</command> to run when things go
wrong.</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>
+
+ <tip>
+ <para>For the best results possible, try to run the same
+ version of Subversion on your master and slave
+ servers.</para>
+ </tip>
+
<sidebar>
<title>Can We Set Up Replication with svnserve?</title>
=======================================
--- /trunk/en/book/ch09-reference.xml Fri Aug 19 09:32:37 2011
+++ /trunk/en/book/ch09-reference.xml Fri Aug 19 10:43:07 2011
@@ -9357,6 +9357,25 @@
</screen>
</informalexample>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>SVNAdvertiseV2Protocol On|Off</literal></term>
+ <listitem>
+
+ <para>New to Subversion 1.7, this toggles
+ whether <command>mod_dav_svn</command> advertises its
+ support for the new version of its HTTP protocol also
+ introduced in that version. Most admins will not wish
+ to use this directive (which is <literal>On</literal>
+ by default), choosing instead to enjoy the performance
+ benefits that the new protocol offers. However, whena
+ configuring a server as a write-through proxy to
+ another server which does not support the new
+ protocol, set this directive's value
+ to <literal>Off</literal>.</para>
+
</listitem>
</varlistentry>
@@ -9414,6 +9433,50 @@
linkend="svn.webdav"/>. The default value of this
directive is <literal>Off</literal>.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>SVNCacheFullTexts On|Off</literal></term>
+ <listitem>
+
+ <para>When set to <literal>On</literal>, this tells
+ Subversion to cache content fulltexts if sufficient
+ in-memory cache is available, which could offer a
+ significant performance benefit to the server. (See
+ also the <literal>SVNInMemoryCacheSize</literal>
+ directive.) The default value of this directive
+ is <literal>Off</literal>.</para>
+
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><literal>SVNCacheTextDeltas On|Off</literal></term>
+ <listitem>
+
+ <para>When set to <literal>On</literal>, this tells
+ Subversion to cache content deltas if sufficient
+ in-memory cache is available, which could offer a
+ significant performance benefit to the server. (See
+ also the <literal>SVNInMemoryCacheSize</literal>
+ directive.) The default value of this directive
+ is <literal>Off</literal>.</para>
+
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>SVNCompressionLevel
+ <replaceable>level</replaceable></literal></term>
+ <listitem>
+
+ <para>Specifies the compression level used when sending
+ file content over the network. A value
+ of <literal>0</literal> disables compression
+ altogether, and <literal>9</literal> is the maximum
+ value. <literal>5</literal> is the default
+ value.</para>
+
</listitem>
</varlistentry>
@@ -9425,6 +9488,20 @@
<para>Specifies the URI of an XSL transformation for
directory indexes. This directive is optional.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>SVNInMemoryCacheSize
+ <replaceable>size</replaceable></literal></term>
+ <listitem>
+
+ <para>Specifies the maximum size (in kbytes) per process
+ of Subversion's in-memory object cache. The default
+ value is <literal>16384</literal>; use a value
+ of <literal>0</literal> to deactivate this cache
+ altogether.</para>
+
</listitem>
</varlistentry>
More information about the svnbook-dev
mailing list