[svnbook commit] r2696 - trunk/src/en/book

[sussman]

Author: sussman
Date: Sat Feb 24 14:51:25 2007
New Revision: 2696

Modified:
   trunk/src/en/book/ch-server-configuration.xml

Log:
 * src/en/book/ch-server-configuration.xml:  some inital changes based on cmpilato's review.

Modified: trunk/src/en/book/ch-server-configuration.xml
==============================================================================
--- trunk/src/en/book/ch-server-configuration.xml	(original)
+++ trunk/src/en/book/ch-server-configuration.xml	Sat Feb 24 14:51:25 2007
@@ -123,11 +123,12 @@
 
       <title>The Apache HTTP Server</title>
 
-      <para>The Apache HTTP Server is a well-establish, full-featured
+      <para>The Apache HTTP Server is a well-established, full-featured
         web server program.  But when you extend this server with the
-        mod_dav_svn Subversion server module, the Apache HTTP Server
-        becomes a Subversion server, too.  Clients speak to server via
-        HTTP or HTTPS, using the WebDAV protocol.</para>
+        <command>mod_dav_svn</command> Subversion server module, the
+        Apache HTTP Server becomes a Subversion server, too.  Clients
+        speak to server via HTTP or HTTPS, using the WebDAV/DeltaV
+        protocol.</para>
 
       <variablelist>
         <varlistentry>
@@ -562,7 +563,17 @@
         <para>If your Windows system is a descendant of Windows NT
           (2000, 2003, XP, Vista), then you can
           run <command>svnserve</command> as a standard Windows
-          service.  You'll need to define the service using a
+          service.  This is typically a much nicer experience than
+          running it as a standalone daemon with
+          the <option>-d</option> option.  Using daemon-mode requires
+          launching a console, typing a command, and then leaving the
+          console window running indefinitely.  A Windows service,
+          however, runs in the background, can start at boot time
+          automatically, and can be started and stopped using the same
+          consistent administration interface as other
+          services. </para>
+
+        <para>You'll need to define the new service using the
           command-line tool <command>SC.EXE</command>.  Much like
           the <command>inetd</command> configuration line, you must
           specify an exact invocation of <command>svnserve</command>
@@ -820,7 +831,7 @@
 
     <!-- =============================================================== -->
     <sect2 id="svn.serverconfig.svnserve.sshauth">
-      <title>SSH authentication and authorization</title>
+      <title>Tunneling over SSH</title>
 
       <para><command>svnserve</command>'s built-in authentication can
         be very handy, because it avoids the need to create real
@@ -1409,6 +1420,13 @@
         </listitem>
       </itemizedlist>
 
+      <para>Of course, you might have already set up
+        a <filename>pre-commit</filename> hook script to prevent
+        commits (see <xref linkend="svn.reposadmin.create.hooks"/>).
+        But as you read on, you'll see that it's also possible use
+        Apache's built-in methods to restrict access in specific
+        ways.</para>
+
       <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
       <sect3 id="svn.serverconfig.httpd.authn.basic">
         <title>Basic HTTP Authentication</title>
@@ -2311,8 +2329,7 @@
       rules-file.</para>
 
     <sidebar>
-      <title>Best practice: do you really need path-based access
-        control?</title>
+      <title>Do you really need path-based access control?</title>
 
       <para>A lot of administrators setting up Subversion for the
         first time tend to jump into path-based access control without
@@ -2359,11 +2376,11 @@
         this book!</para></footnote>.</para>
 
       <para>As an example to ponder, consider that the Subversion
-        project itself has always a notion of who is allowed to commit
-        where, but it's always been enforced socially.  This is a good
-        model of community trust, especially for open-source projects.
-        Of course, sometimes there <emphasis>are</emphasis> truly
-        legitimate needs for path-based access control; within
+        project itself has always had a notion of who is allowed to
+        commit where, but it's always been enforced socially.  This is
+        a good model of community trust, especially for open-source
+        projects.  Of course, sometimes there <emphasis>are</emphasis>
+        truly legitimate needs for path-based access control; within
         corporations, for example, certain types of data really can be
         sensitive, and access needs to be genuinely restricted to
         small groups of people.</para>
@@ -2516,8 +2533,6 @@
 everyone = @calc-developers, @paint-developers
 </screen>
 
-    <para>…and that's pretty much all there is to it.</para>
-
   </sect1>