[svnbook commit] r3060 - trunk/src/en/book
sussman
noreply at red-bean.com
Sun May 4 20:25:28 CDT 2008
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>
More information about the svnbook-dev
mailing list