[svnbook] r3940 committed - * src/en/book/appb-svn-for-cvs-users.xml, ...
svnbook at googlecode.com
svnbook at googlecode.com
Fri Jul 29 15:12:34 CDT 2011
Revision: 3940
Author: cmpilato at gmail.com
Date: Fri Jul 29 13:11:52 2011
Log: * src/en/book/appb-svn-for-cvs-users.xml,
* src/en/book/appc-webdav.xml
Read-thru updates and edits.
http://code.google.com/p/svnbook/source/detail?r=3940
Modified:
/trunk/src/en/book/appb-svn-for-cvs-users.xml
/trunk/src/en/book/appc-webdav.xml
=======================================
--- /trunk/src/en/book/appb-svn-for-cvs-users.xml Tue Jul 26 12:41:33 2011
+++ /trunk/src/en/book/appb-svn-for-cvs-users.xml Fri Jul 29 13:11:52 2011
@@ -391,12 +391,11 @@
when a conflict occurs in a file, Subversion records the fact
that the file is in a state of conflict, and won't allow you to
commit changes to that file until you explicitly resolve the
- conflict. Second, Subversion 1.5 provides interactive
- conflict resolution, which allows you to resolve conflicts as
- they happen instead of having to go back and do so after the
- update or merge operation completes. See <xref
- linkend="svn.tour.cycle.resolve" /> for more about conflict
- resolution in Subversion.</para>
+ conflict. Second, Subversion provides interactive conflict
+ resolution, which allows you to resolve conflicts as they happen
+ instead of having to go back and do so after the update or merge
+ operation completes. See <xref linkend="svn.tour.cycle.resolve"
+ /> for more about conflict resolution in Subversion.</para>
</sect1>
@@ -421,12 +420,12 @@
<para>Subversion takes the more paranoid route. First, it never
performs any kind of keyword or line-ending translation unless
- you explicitly ask it to do so (see <xref
- linkend="svn.advanced.props.special.keywords"/> and <xref
- linkend="svn.advanced.props.special.eol-style"/> for more details).
By default,
- Subversion treats all file data as literal byte strings, and
- files are always stored in the repository in an untranslated
- state.</para>
+ you explicitly ask it to do so (see
+ <xref linkend="svn.advanced.props.special.keywords"/> and
+ <xref linkend="svn.advanced.props.special.eol-style"/> for more
+ details). By default, Subversion treats all file data as
+ literal byte strings, and files are always stored in the
+ repository in an untranslated state.</para>
<para>Second, Subversion maintains an internal notion of whether a
file is <quote>text</quote> or <quote>binary</quote> data, but
=======================================
--- /trunk/src/en/book/appc-webdav.xml Tue Jul 26 12:51:54 2011
+++ /trunk/src/en/book/appc-webdav.xml Fri Jul 29 13:11:52 2011
@@ -92,16 +92,16 @@
specification were irrelevant to Subversion, and thus were left
unimplemented.</para>
- <para>There is still some debate in the developer community as to
- whether or not it's worthwhile to remedy either of these
- situations. It's fairly unrealistic to change Subversion's
- design to match DeltaV, so there's probably no way the client
- can ever learn to get everything it needs from a general DeltaV
- server. On the other hand,
- <command>mod_dav_svn</command> <emphasis>could</emphasis> be
- further developed to implement all of DeltaV, but it's hard to
- find motivation to do so—there are almost no DeltaV
- clients to interoperate with.</para>
+ <para>A long-held debate in the Subversion developer community
+ about whether it was worthfile to remedy either of these
+ situations eventually reached closure, with the Subversion
+ developers officially deciding to abandon plans to fully support
+ DeltaV. New versions of Subversion will, of course, continue to
+ provide the same DeltaV feature support already present in older
+ releases, but no new work would be done to increase coverage of
+ the specification—in fact, Subversion would intentionally
+ begin to move away from strict DeltaV as its primary HTTP-based
+ protocol.</para>
</sect1>
@@ -143,21 +143,20 @@
user) can still use a Subversion client to search history and
retrieve older versions of data.</para>
- <para>This scenario isn't fiction—it's real and it works, as
- of Subversion 1.2 and later. To activate autoversioning in
- <command>mod_dav_svn</command>, use the
- <literal>SVNAutoversioning</literal> directive within the
- <filename>httpd.conf</filename> <literal>Location</literal>
+ <para>This scenario isn't fiction—it's real and it works.
+ To activate autoversioning in <command>mod_dav_svn</command>,
+ use the <literal>SVNAutoversioning</literal> directive within
+ the <filename>httpd.conf</filename> <literal>Location</literal>
block, like so:</para>
<informalexample>
- <screen>
+ <programlisting>
<Location /repos>
DAV svn
SVNPath /var/svn/repository
SVNAutoversioning on
</Location>
-</screen>
+</programlisting>
</informalexample>
<para>When Subversion autoversioning is active, write requests
@@ -645,9 +644,9 @@
<para>Also, OS X's WebDAV client can sometimes be overly
sensitive to HTTP redirects. If OS X is unable to mount the
- repository at all, you may need to enable the
<literal>BrowserMatch</literal>
- directive in the Apache server's
- <filename>httpd.conf</filename>:</para>
+ repository at all, you may need to enable
+ the <literal>BrowserMatch</literal> directive in the Apache
+ server's <filename>httpd.conf</filename>:</para>
<informalexample>
<programlisting>
@@ -661,11 +660,11 @@
<sect3 id="svn.webdav.clients.fs-impl.linux">
<title>Linux davfs2</title>
- <para>Linux davfs2 is a filesystem module for the Linux kernel,
- whose development is organized at <ulink
- url="http://dav.sourceforge.net/"/>. Once you install
- davfs2, you can mount a WebDAV network share using the usual
Linux mount
- command:</para>
+ <para>Linux davfs2 is a filesystem module for the Linux
+ kernel, whose development is organized at
+ <ulink url="http://dav.sourceforge.net/"/>. Once you
+ install davfs2, you can mount a WebDAV network share using
+ the usual Linux mount command:</para>
<informalexample>
<screen>
More information about the svnbook-dev
mailing list