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

[sussman]

Author: sussman
Date: Sun May  4 20:25:28 2008
New Revision: 3060

Log:
* ch06-server-configuration.xml: fix issue 103.

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

Modified: trunk/src/en/book/ch06-server-configuration.xml
==============================================================================
--- trunk/src/en/book/ch06-server-configuration.xml	(original)
+++ trunk/src/en/book/ch06-server-configuration.xml	Sun May  4 20:25:28 2008
@@ -3179,16 +3179,16 @@
       </listitem>
     </itemizedlist>
 
-    <para>The most common problem administrators run into is repository
-      ownership and permissions.  Does every process (or user) in the
-      previous list have the rights to read and write the Berkeley DB
-      files?  Assuming you have a Unix-like operating system, a
-      straightforward approach might be to place every potential
-      repository user into a new <literal>svn</literal> group, and
-      make the repository wholly owned by that group.  But even that's
-      not enough, because a process may write to the database files
-      using an unfriendly umask—one that prevents access by
-      other users.</para>
+    <para>The most common problem administrators run into is
+      repository ownership and permissions.  Does every process (or
+      user) in the previous list have the rights to read and write the
+      repository's underlying data files?  Assuming you have a
+      Unix-like operating system, a straightforward approach might be
+      to place every potential repository user into a
+      new <literal>svn</literal> group, and make the repository wholly
+      owned by that group.  But even that's not enough, because a
+      process may write to the database files using an unfriendly
+      umask—one that prevents access by other users.</para>
 
     <para>So the next step beyond setting up a common group for
       repository users is to force every repository-accessing process
@@ -3212,14 +3212,15 @@
 </screen>
 
     <para>Another common problem is often encountered on Unix-like
-      systems.  As a repository is used, Berkeley DB occasionally
-      creates new log files to journal its actions.  Even if the
-      repository is wholly owned by the <command>svn</command> group,
-      these newly created files won't necessarily be owned by that
-      same group, which then creates more permissions problems for
-      your users.  A good workaround is to set the group SUID bit on
-      the repository's <filename>db</filename> directory. This causes
-      all newly created log files to have the same group owner as the
+      systems.  If your repository is backed by Berkeley DB, for
+      example, it occasionally creates new log files to journal its
+      actions.  Even if the Berkeley DB repository is wholly owned by
+      the <command>svn</command> group, these newly created log files
+      won't necessarily be owned by that same group, which then
+      creates more permissions problems for your users.  A good
+      workaround is to set the group SUID bit on the
+      repository's <filename>db</filename> directory. This causes all
+      newly created log files to have the same group owner as the
       parent directory.</para>
 
     <para>Once you've jumped through these hoops, your repository
@@ -3238,8 +3239,8 @@
       <literal>http://</literal> or <literal>svn://</literal> URLs.
       And maintaining multiple server processes for your Subversion
       repositories is likely to be more of a headache than necessary.
-      We recommend you choose the server that best meets your needs
-      and stick with it!</para>
+      We recommend you choose a single server that best meets your
+      needs and stick with it!</para>
 
     <sidebar>
       <title>The svn+ssh:// Server Checklist</title>