[svnbook commit] r3237 - trunk/src/en/book
sussman
noreply at red-bean.com
Sun Aug 3 21:37:41 CDT 2008
Author: sussman
Date: Sun Aug 3 21:37:41 2008
New Revision: 3237
Log:
Enter 2nd-round copyedits (most of them) to chapter 6.
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 Aug 3 21:37:41 2008
@@ -12,7 +12,7 @@
exposed outside its host machine for use by remote clients. We
will cover Subversion's currently available server mechanisms,
discussing the configuration and use of each. After reading this
- section, you should be able to decide which networking setup is
+ chapter, you should be able to decide which networking setup is
right for your needs, as well as understand how to enable such a
setup on your host computer.</para>
@@ -61,7 +61,7 @@
also used exclusively to authenticate, so real system accounts
are required on the server host (unlike
vanilla <command>svnserve</command>, which has its own private
- user accounts.) Finally, because this setup requires that each
+ user accounts). Finally, because this setup requires that each
user spawn a private, temporary <command>svnserve</command>
process, it's equivalent (from a permissions point of view) to
allowing a group of local users to all access the repository
@@ -87,9 +87,9 @@
<row>
<entry>Authentication options</entry>
<entry>HTTP(S) basic auth, X.509 certificates, LDAP, NTLM, or
- any other mechanism available to Apache httpd.</entry>
+ any other mechanism available to Apache httpd</entry>
<entry>CRAM-MD5 by default; LDAP, NTLM, or any other mechanism
- available to SASL.</entry>
+ available to SASL</entry>
<entry>SSH</entry>
</row>
@@ -98,71 +98,71 @@
<entry>Private 'users' file, or other mechanisms
available to Apache httpd (LDAP, SQL, etc.)</entry>
<entry>Private 'users' file, or other mechanisms available
- to SASL (LDAP, SQL, etc.).</entry>
- <entry>System accounts.</entry>
+ to SASL (LDAP, SQL, etc.)</entry>
+ <entry>System accounts</entry>
</row>
<row>
<entry>Authorization options</entry>
<entry>Read/write access can be granted over the whole
- repository, or specified per path.</entry>
+ repository, or specified per path</entry>
<entry>Read/write access can be granted over the whole
- repository, or specified per path.</entry>
+ repository, or specified per path</entry>
<entry>Read/write access only grantable over the whole
- repository.</entry>
+ repository</entry>
</row>
<row>
<entry>Encryption</entry>
- <entry>Available via optional SSL.</entry>
- <entry>Available via optional SASL features.</entry>
- <entry>Inherent in SSH connection.</entry>
+ <entry>Available via optional SSL</entry>
+ <entry>Available via optional SASL features</entry>
+ <entry>Inherent in SSH connection</entry>
</row>
<row>
<entry>Logging</entry>
<entry>Full Apache logs of each HTTP request, with
optional <quote>high-level</quote> logging of general
- client operations.</entry>
- <entry>No logging.</entry>
- <entry>No logging.</entry>
+ client operations</entry>
+ <entry>No logging</entry>
+ <entry>No logging</entry>
</row>
<row>
<entry>Interoperability</entry>
- <entry>Accessible by other WebDAV clients.</entry>
- <entry>Talks only to svn clients.</entry>
- <entry>Talks only to svn clients.</entry>
+ <entry>Accessible by other WebDAV clients</entry>
+ <entry>Talks only to svn clients</entry>
+ <entry>Talks only to svn clients</entry>
</row>
<row>
<entry>Web viewing</entry>
<entry>Limited built-in support, or via third-party tools
- such as ViewVC.</entry>
- <entry>Only via third-party tools such as ViewVC.</entry>
- <entry>Only via third-party tools such as ViewVC.</entry>
+ such as ViewVC</entry>
+ <entry>Only via third-party tools such as ViewVC</entry>
+ <entry>Only via third-party tools such as ViewVC</entry>
</row>
<row>
<entry>Master-slave server replication</entry>
- <entry>Transparent write-proxying available from slave to master.</entry>
- <entry>Can only create read-only slave servers.</entry>
- <entry>Can only create read-only slave servers.</entry>
+ <entry>Transparent write-proxying available from slave to master</entry>
+ <entry>Can only create read-only slave servers</entry>
+ <entry>Can only create read-only slave servers</entry>
</row>
<row>
<entry>Speed</entry>
- <entry>Somewhat slower.</entry>
- <entry>Somewhat faster.</entry>
- <entry>Somewhat faster.</entry>
+ <entry>Somewhat slower</entry>
+ <entry>Somewhat faster</entry>
+ <entry>Somewhat faster</entry>
</row>
<row>
<entry>Initial setup</entry>
- <entry>Somewhat complex.</entry>
- <entry>Extremely simple.</entry>
- <entry>Moderately simple.</entry>
+ <entry>Somewhat complex</entry>
+ <entry>Extremely simple</entry>
+ <entry>Moderately simple</entry>
</row>
</tbody>
@@ -179,7 +179,7 @@
<para>Obviously, there's no right answer to that question. Every
team has different needs, and the different servers all
- represent different sets of tradeoffs. The Subversion project
+ represent different sets of trade-offs. The Subversion project
itself doesn't endorse one server or another, or consider either
server more <quote>official</quote> than another.</para>
@@ -189,7 +189,7 @@
<sect2 id="svn.serverconfig.choosing.svnserve">
- <title>The <command>svnserve</command> Server</title>
+ <title>The svnserve Server</title>
<variablelist>
<varlistentry>
@@ -198,16 +198,16 @@
<itemizedlist>
<listitem><para>Quick and easy to set
- up.</para></listitem>
+ up</para></listitem>
<listitem><para>Network protocol is stateful and
- noticeably faster than WebDAV.</para></listitem>
+ noticeably faster than WebDAV</para></listitem>
<listitem><para>No need to create system accounts on
- server.</para></listitem>
+ server</para></listitem>
<listitem><para>Password is not passed over the
- network.</para></listitem>
+ network</para></listitem>
</itemizedlist>
</listitem>
@@ -241,7 +241,7 @@
<sect2 id="svn.serverconfig.choosing.svn-ssh">
- <title><command>svnserve</command> over SSH</title>
+ <title>svnserve over SSH</title>
<variablelist>
<varlistentry>
@@ -249,7 +249,7 @@
<listitem>
<itemizedlist>
- <listitem><para>Network protocol is stateful and
+ <listitem><para>The network protocol is stateful and
noticeably faster than WebDAV.</para></listitem>
<listitem><para>You can take advantage of existing SSH
@@ -268,15 +268,15 @@
<itemizedlist>
<listitem><para>Only one choice of authentication
- method.</para></listitem>
+ method is available.</para></listitem>
- <listitem><para>No logging of any kind, not even
+ <listitem><para>There is no logging of any kind, not even
errors.</para></listitem>
- <listitem><para>Requires users to be in same system group, or
+ <listitem><para>It requires users to be in the same system group, or
use a shared SSH key.</para></listitem>
- <listitem><para>If used improperly, can lead to file permissions
+ <listitem><para>If used improperly, it can lead to file permission
problems.</para></listitem>
</itemizedlist>
@@ -297,14 +297,14 @@
<listitem>
<itemizedlist>
- <listitem><para>Allows Subversion to use any of the
+ <listitem><para>It allows Subversion to use any of the
numerous authentication systems already integrated
with Apache.</para></listitem>
- <listitem><para>No need to create system accounts on
- server.</para></listitem>
+ <listitem><para>There is no need to create system accounts on
+ the server.</para></listitem>
- <listitem><para>Full Apache logging.</para></listitem>
+ <listitem><para>Full Apache logging is available.</para></listitem>
<listitem><para>Network traffic can be encrypted via
SSL.</para></listitem>
@@ -312,10 +312,10 @@
<listitem><para>HTTP(S) can usually go through corporate
firewalls.</para></listitem>
- <listitem><para>Built-in repository browsing via web
- browser.</para></listitem>
+ <listitem><para>Built-in repository browsing is
+ available via web browser.</para></listitem>
- <listitem><para>Repository can be mounted as a network
+ <listitem><para>The repository can be mounted as a network
drive for transparent version control (see
<xref
linkend="svn.webdav.autoversioning"/>).</para></listitem>
@@ -351,7 +351,7 @@
<para>In general, the authors of this book recommend a vanilla
<command>svnserve</command> installation for small teams just
trying to get started with a Subversion server; it's the
- simplest to set up, and has the fewest maintenance issues.
+ simplest to set up and has the fewest maintenance issues.
You can always switch to a more complex server
deployment as your needs change.</para>
@@ -361,13 +361,13 @@
<itemizedlist>
<listitem>
<para>If you're trying to set up the simplest possible
- server for your group, then a
+ server for your group, a
vanilla <command>svnserve</command> installation is the
easiest, fastest route. Note, however, that your
repository data will be transmitted in the clear over the
network. If your deployment is entirely within your
company's LAN or VPN, this isn't an issue. If the
- repository is exposed to the wide-open Internet, then you
+ repository is exposed to the wide-open Internet, you
might want to make sure that either the repository's
contents aren't sensitive (e.g., it contains only
open source code), or that you go the extra mile in
@@ -376,11 +376,11 @@
<listitem>
<para>If you need to integrate with existing legacy identity
- systems (LDAP, Active Directory, NTLM, X.509, etc.), then
+ systems (LDAP, Active Directory, NTLM, X.509, etc.),
you must use either the Apache-based server
or <command>svnserve</command> configured with SASL. If
you absolutely need server-side logs of either server
- errors or client activities, then an Apache-based server
+ errors or client activities, an Apache-based server
is your only option.</para>
</listitem>
@@ -397,9 +397,9 @@
process itself.</para> </listitem>
<listitem>
- <para>If you have an existing infrastructure heavily based
+ <para>If you have an existing infrastructure that is heavily based
on SSH accounts, and if your users already have system
- accounts on your server machine, then it makes sense to
+ accounts on your server machine, it makes sense to
deploy an <command>svnserve</command>-over-SSH solution.
Otherwise, we don't widely recommend this option to the
public. It's generally considered safer to have your
@@ -415,13 +415,13 @@
<para>Do <emphasis>not</emphasis> be seduced by the simple
idea of having all of your users access a repository
directly via <literal>file://</literal> URLs. Even if the
- repository is readily available to everyone via network
+ repository is readily available to everyone via a network
share, this is a bad idea. It removes any layers of
protection between the users and the repository: users can
accidentally (or intentionally) corrupt the repository
database, it becomes hard to take the repository offline
for inspection or upgrade, and it can lead to a mess of
- file-permissions problems (see <xref
+ file permission problems (see <xref
linkend="svn.serverconfig.multimethod"/>). Note that this
is also one of the reasons we warn against accessing
repositories via <literal>svn+ssh://</literal>
@@ -440,7 +440,7 @@
<!-- ================================================================= -->
<sect1 id="svn.serverconfig.svnserve">
- <title><command>svnserve</command>, a Custom Server</title>
+ <title>svnserve, a Custom Server</title>
<para>The <command>svnserve</command> program is a lightweight
server, capable of speaking to clients over TCP/IP using a
@@ -475,7 +475,7 @@
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<sect3 id="svn.serverconfig.svnserve.invoking.daemon">
- <title><command>svnserve</command> as daemon</title>
+ <title>svnserve as daemon</title>
<para>The easiest option is to run <command>svnserve</command>
as a standalone <quote>daemon</quote> process. Use the
@@ -496,7 +496,7 @@
available to the network. A client needs to specify an
<emphasis>absolute</emphasis> path in the repository URL. For
example, if a repository is located at
- <filename>/var/svn/project1</filename>, then a client would
+ <filename>/var/svn/project1</filename>, a client would
reach it via
<uri>svn://host.example.com/var/svn/project1</uri>. To
increase security, you can pass the <option>-r</option> option
@@ -524,14 +524,14 @@
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<sect3 id="svn.serverconfig.svnserve.invoking.inetd">
- <title><command>svnserve</command> via <command>inetd</command></title>
+ <title>svnserve via inetd</title>
<para>If you want <command>inetd</command> to launch the
- process, then you need to pass the <option>-i</option>
+ process, you need to pass the <option>-i</option>
(<option>--inetd</option>) option. In the following
example, we've shown the output from running
<literal>svnserve -i</literal> at the command line, but note
- that isn't how you actually start the daemon; see the
+ that this isn't how you actually start the daemon; see the
paragraphs following the example for how to configure
<command>inetd</command> to start
<command>svnserve</command>.</para>
@@ -577,7 +577,7 @@
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<sect3 id="svn.serverconfig.svnserve.invoking.tunnel">
- <title><command>svnserve</command> over a tunnel</title>
+ <title>svnserve over a tunnel</title>
<para>A third way to invoke <command>svnserve</command> is in
tunnel mode, using the <option>-t</option> option. This
@@ -608,10 +608,10 @@
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<sect3 id="svn.serverconfig.svnserve.invoking.winservice">
- <title><command>svnserve</command> as Windows service</title>
+ <title>svnserve as Windows service</title>
<para>If your Windows system is a descendant of Windows NT
- (2000, 2003, XP, or Vista), then you can
+ (2000, 2003, XP, or Vista), you can
run <command>svnserve</command> as a standard Windows
service. This is typically a much nicer experience than
running it as a standalone daemon with the <option>--daemon
@@ -657,10 +657,10 @@
value</literal> patterns must have no spaces between
<literal>key=</literal> and must have exactly one space
before the <literal>value</literal>. Lastly, be careful
- about spaces in your commandline to be invoked. If a
+ about spaces in your command line to be invoked. If a
directory name contains spaces (or other characters that
need escaping), place the entire inner value of
- <literal>binpath</literal> in double-quotes, by escaping
+ <literal>binpath</literal> in double quotes, by escaping
them:</para>
<screen>
@@ -674,7 +674,7 @@
<para>Also note that the word <literal>binpath</literal> is
misleading—its value is a <emphasis>command
line</emphasis>, not the path to an executable. That's why
- you need to surround it with quote marks if it contains
+ you need to surround it with quotes if it contains
embedded spaces.</para>
<para>Once the service is defined, it can be stopped, started,
@@ -687,7 +687,7 @@
C:\> net start svn
</screen>
- <para>The service can also be uninstalled (i.e. undefined) by
+ <para>The service can also be uninstalled (i.e., undefined) by
deleting its definition: <userinput>sc delete svn</userinput>.
Just be sure to stop the service first!
The <command>SC.EXE</command> program has many other
@@ -715,7 +715,7 @@
describes.</para></listitem>
<listitem><para>Depending on the defined policies, one of the
- following may accur:</para>
+ following may occur:</para>
<itemizedlist>
<listitem><para>The client may be allowed to make requests
@@ -734,10 +734,9 @@
</itemizedlist>
<para>The <command>svnserve</command> server, by default, knows
- only how to send a CRAM-MD5
- <footnote>
+ only how to send a CRAM-MD5<footnote>
<para>See RFC 2195.</para>
- </footnote>
+ </footnote>
authentication challenge. In essence,
the server sends a small amount of data to the client. The
client uses the MD5 hash algorithm to create a fingerprint of
@@ -748,8 +747,8 @@
network.</emphasis></para>
<para>If your <command>svnserve</command> server was built with
- SASL, then it not only knows how to send CRAM-MD5 challenges,
- but likely knows a whole host of other authentication
+ SASL support, it not only knows how to send CRAM-MD5 challenges,
+ but also likely knows a whole host of other authentication
mechanisms. See <xref
linkend="svn.serverconfig.svnserve.sasl"/> later in this
chapter to learn how to configure SASL authentication and
@@ -760,15 +759,15 @@
<command>ssh</command>. In that case, the server simply
examines the user it's running as, and uses this name as the
authenticated username. For more on this, see the later
- section <xref
+ section, <xref
linkend="svn.serverconfig.svnserve.sshauth"/>.</para>
<para>As you've already guessed, a repository's
<filename>svnserve.conf</filename> file is the central
mechanism for controlling authentication and authorization
policies. The file has the same format as other configuration
- files (see <xref linkend="svn.advanced.confarea"/> in chapter
- 7): section names are marked by square brackets
+ files (see <xref linkend="svn.advanced.confarea"/>):
+ section names are marked by square brackets
(<literal>[</literal> and <literal>]</literal>), comments
begin with hashes (<literal>#</literal>), and each section
contains specific variables that can be set (<literal>variable
@@ -779,7 +778,7 @@
<sect3 id="svn.serverconfig.svnserve.auth.users">
<title>Create a users file and realm</title>
- <para>For now, the <literal>[general]</literal> section of the
+ <para>For now, the <literal>[general]</literal> section of
<filename>svnserve.conf</filename> has all the variables you
need. Begin by changing the values of those variables:
choose a name for a file that will contain your usernames
@@ -821,7 +820,7 @@
authentication realm. Wherever the file lives, be sure to
set the file's read and write permissions appropriately. If
you know which user(s) <command>svnserve</command> will run
- as, restrict read access to the user file as necessary.</para>
+ as, restrict read access to the users file as necessary.</para>
</sect3>
@@ -833,7 +832,7 @@
<filename>svnserve.conf</filename> file: they determine what
unauthenticated (anonymous) and authenticated users are
allowed to do. The variables <literal>anon-access</literal>
- and <literal>auth-access</literal> can be set to the values
+ and <literal>auth-access</literal> can be set to the value
<literal>none</literal>, <literal>read</literal>, or
<literal>write</literal>. Setting the value to
<literal>none</literal> prohibits both reading and writing;
@@ -870,7 +869,7 @@
auth-access = write
</screen>
- <para>The server process not only understands
+ <para>The server process understands not only
these <quote>blanket</quote> access controls to the
repository, but also finer-grained access restrictions placed
on specific files and directories within the repository. To
@@ -887,13 +886,13 @@
authz-db = authzfile
</screen>
- <para>The syntax of the <filename>authzfile</filename> file is
- discussed in detail later in this chapter in
+ <para>We discuss the syntax of the <filename>authzfile</filename> file
+ in detail later in this chapter, in
<xref linkend="svn.serverconfig.pathbasedauthz"/>. Note
that the <literal>authz-db</literal> variable isn't mutually
exclusive with the <literal>anon-access</literal>
and <literal>auth-access</literal> variables; if all the
- variables are defined at once, then <emphasis>all</emphasis>
+ variables are defined at once, <emphasis>all</emphasis>
of the rules must be satisfied before access is allowed.</para>
</sect3>
@@ -907,7 +906,7 @@
all they need from <command>svnserve</command>. However, if
your server (and your Subversion clients) were built with the
Cyrus Simple Authentication and Security Layer (SASL) library,
- then you have a number of authentication and encryption
+ you have a number of authentication and encryption
options available to you.</para>
<sidebar>
@@ -949,7 +948,7 @@
aren't present, the client and server inherently know how to
use the CRAM-MD5 and ANONYMOUS mechanisms (see
<xref linkend="svn.serverconfig.svnserve.auth"/>). If server
- and client were linked against SASL, then a number of other
+ and client were linked against SASL, a number of other
authentication mechanisms may also be available. However,
you'll need to explicitly configure SASL on the server side to
advertise them.</para>
@@ -994,7 +993,7 @@
<para>Because SASL provides so many different kinds of
authentication mechanisms, it would be foolish (and far
- beyond the scope of this book) to try and describe every
+ beyond the scope of this book) to try to describe every
possible server-side configuration. Instead, we recommend
that you read the documentation supplied in the
<filename>doc/</filename> subdirectory of the SASL source
@@ -1013,7 +1012,7 @@
mech_list: DIGEST-MD5
</screen>
- <para>then you've told SASL to advertise the DIGEST-MD5
+ <para>you've told SASL to advertise the DIGEST-MD5
mechanism to clients and to check user passwords against a
private password database located
at <filename>/etc/my_sasldb</filename>. A system
@@ -1025,7 +1024,7 @@
$ saslpasswd2 -c -f /etc/my_sasldb -u realm username
</screen>
- <para>A few words of warning: first, make sure that the
+ <para>A few words of warning: first, make sure the
<quote>realm</quote> argument
to <command>saslpasswd2</command> matches the same realm
you've defined in your
@@ -1033,7 +1032,7 @@
they don't match, authentication will fail. Also, due to a
shortcoming in SASL, the common realm must be a string with
no space characters. Finally, if you decide to go with the
- standard SASL password database, make sure that
+ standard SASL password database, make sure
the <command>svnserve</command> program has read access to
the file (and possibly write access as well, if you're using
a mechanism such as OTP).</para>
@@ -1050,7 +1049,7 @@
Subversion client built without SASL support (which includes
all pre-1.5 clients) will be unable to authenticate. On the
one hand, this sort of restriction may be exactly what you
- want (<quote>my clients must all use Kerberos!</quote>).
+ want (<quote>My clients must all use Kerberos!</quote>).
However, if you still want non-SASL clients to be able to
authenticate, be sure to advertise the CRAM-MD5 mechanism as
an option. All clients are able to use CRAM-MD5, whether
@@ -1084,7 +1083,7 @@
guarantee data integrity without encryption), set both
values to 1. If you wish to allow—but not
require—encryption, set the minimum value to 0, and
- the maximum value to some bit-length. To require encryption
+ the maximum value to some bit length. To require encryption
unconditionally, set both values to numbers greater than 1.
In our previous example, we require clients to do at least
128-bit encryption, but no more than 256-bit
@@ -1172,21 +1171,21 @@
place them into a common group, and you'll need to be careful
about umasks (be sure to read <xref
linkend="svn.serverconfig.multimethod"/> later in this
- chapter). But even in the case of tunneling, the
- <filename>svnserve.conf</filename> file can still be used to
- block access, by simply setting <literal>auth-access =
- read</literal> or <literal>auth-access = none</literal>.
- <footnote> <para>Note that using any sort of
+ chapter). But even in the case of tunneling, you can still use the
+ <filename>svnserve.conf</filename> file to block access, by
+ simply setting <literal>auth-access = read</literal>
+ or <literal>auth-access = none</literal><footnote> <para>Note
+ that using any sort of
<command>svnserve</command>-enforced access control at all is
a bit pointless; the user already has direct access to the
- repository database.</para> </footnote> </para>
+ repository database.</para> </footnote>. </para>
<para>You'd think that the story of SSH tunneling would end
here, but it doesn't. Subversion allows you to create custom
tunnel behaviors in your runtime <filename>config</filename>
file (see <xref linkend="svn.advanced.confarea"/>.) For
- example, suppose you want to use RSH instead of SSH.
- <footnote> <para>We don't actually recommend this, since RSH
+ example, suppose you want to use RSH instead of SSH.<footnote>
+ <para>We don't actually recommend this, since RSH
is notably less secure than SSH.</para> </footnote> In the
<literal>[tunnels]</literal> section of your
<filename>config</filename> file, simply define it like
@@ -1202,7 +1201,7 @@
<literal>svn+rsh://host/path</literal>. When using the new
URL scheme, the Subversion client will actually be running the
command <userinput>rsh host svnserve -t</userinput> behind the
- scenes. If you include a username in the URL (for example,
+ scenes. If you include a username in the URL (e.g.,
<literal>svn+rsh://username@host/path</literal>), the client
will also include that in its command (<userinput>rsh
username at host svnserve -t</userinput>). But you can define new
@@ -1217,7 +1216,7 @@
shows how to make the Subversion client launch a very specific
tunneling binary (the one located at
<filename>/opt/alternate/ssh</filename>) with specific
- options. In this case, accessing a
+ options. In this case, accessing an
<literal>svn+joessh://</literal> URL would invoke the
particular SSH binary with <option>-p 29934</option> as
arguments—useful if you want the tunnel program to
@@ -1243,7 +1242,7 @@
<sect2 id="svn.serverconfig.svnserve.sshtricks">
<title>SSH configuration tricks</title>
- <para>It's not only possible to control the way in which the
+ <para>It's possible to control not only the way in which the
client invokes <command>ssh</command>, but also to control
the behavior of <command>sshd</command> on your server
machine. In this section, we'll show how to control the
@@ -1323,7 +1322,7 @@
<para>It's also possible to have multiple users share a single
account. Instead of creating a separate system account for
- each user, generate a public/private key-pair for each
+ each user, generate a public/private key pair for each
person. Then place each public key into
the <filename>authorized_users</filename> file, one per
line, and use the <option>--tunnel-user</option>
@@ -1335,7 +1334,7 @@
</screen>
<para>This example allows both Harry and Sally to connect to
- the same account via public-key authentication. Each of
+ the same account via public key authentication. Each of
them has a custom command that will be executed;
the <option>--tunnel-user</option> option
tells <command>svnserve</command> to assume that the named
@@ -1350,7 +1349,7 @@
the <literal>command</literal> value
in <filename>authorized_keys</filename>. For example, the
user may still get shell access through SSH or be able to
- perform X11 or general port-forwarding through your server.
+ perform X11 or general port forwarding through your server.
To give the user as little permission as possible, you may
want to specify a number of restrictive options immediately
after the <literal>command</literal>:</para>
@@ -1381,7 +1380,7 @@
<title>httpd, the Apache HTTP Server</title>
- <para>The Apache HTTP Server is a <quote>heavy duty</quote>
+ <para>The Apache HTTP Server is a <quote>heavy-duty</quote>
network server that Subversion can leverage. Via a custom
module, <command>httpd</command> makes Subversion repositories
available to clients via the WebDAV/DeltaV protocol, which is an
@@ -1427,13 +1426,13 @@
<para>If you're a system administrator, it's very likely that
you're already running the Apache web server and have some
- prior experience with it. At the time of writing, Apache 1.3
- is by far the most popular version of Apache. The world has
- been somewhat slow to upgrade to the Apache 2.X series for
+ prior experience with it. At the time of this writing, Apache 1.3
+ iss the more popular version of Apache. The world has
+ been somewhat slow to upgrade to the Apache 2.x series for
various reasons: some people fear change, especially changing
something as critical as a web server. Other people depend on
plug-in modules that work only against the Apache 1.3 API, and
- they are waiting for a 2.X port. Whatever the reason, many
+ they are waiting for a 2.x port. Whatever the reason, many
people begin to worry when they first discover that
Subversion's Apache module is written specifically for the
Apache 2 API.</para>
@@ -1470,7 +1469,7 @@
the <command>mod_dav</command> module</para>
</listitem>
<listitem>
- <para>Installing the <command>mod_dav_svn</command> back end
+ <para>Installing the <command>mod_dav_svn</command> backend
to <command>mod_dav</command>, which uses Subversion's
libraries to access the repository</para>
</listitem>
@@ -1582,8 +1581,7 @@
are actually Subversion repositories. This is a particularly
convenient syntax in that, unlike the use of the
<literal>SVNPath</literal> directive, you don't have to
- restart Apache in order to create and network new
- repositories.</para>
+ restart Apache to create and network new repositories.</para>
<para>Be sure that when you define your new
<literal>Location</literal>, it doesn't overlap with other
@@ -1621,7 +1619,7 @@
<para>If you are using Apache's virtual hosting support via
the <literal>NameVirtualHost</literal> directive, you may
need to use the <literal>ServerAlias</literal> directive to
- specify additional names that your server is known by.
+ specify additional names by which your server is known.
Again, refer to the Apache documentation for full
details.</para>
</sidebar>
@@ -1660,7 +1658,7 @@
<title>Authentication Options</title>
<para>At this point, if you configured
- <filename>httpd.conf</filename> to contain something like the
+ <filename>httpd.conf</filename> to contain something such as the
following:</para>
<screen>
@@ -1670,7 +1668,7 @@
</Location>
</screen>
- <para>then your repository is <quote>anonymously</quote>
+ <para>your repository is <quote>anonymously</quote>
accessible to the world. Until you configure some
authentication and authorization policies, the Subversion
repositories that you make available via the
@@ -1696,7 +1694,7 @@
<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
+ But as you read on, you'll see that it's also possible to use
Apache's built-in methods to restrict access in specific
ways.</para>
@@ -1737,7 +1735,7 @@
<literal>AuthName</literal> is an arbitrary name that you
give for the authentication domain. Most browsers will
display this name in the pop-up dialog box when the browser
- is querying the user for his name and password. Finally,
+ is querying the user for her name and password. Finally,
use the <literal>AuthUserFile</literal> directive to specify
the location of the password file you created using
<command>htpasswd</command>.</para>
@@ -1785,10 +1783,10 @@
authorization policies.</para>
<para>One word of warning: HTTP Basic Auth passwords pass in
- very nearly plain-text over the network, and thus are
+ very nearly plain text over the network, and thus are
extremely insecure.</para>
- <para>Another option is to not use Basic authentication but to
+ <para>Another option is to not use Basic authentication, but to
use Digest authentication instead. Digest authentication
allows the server to verify the client's
identity <emphasis>without</emphasis> passing the plain-text
@@ -1798,7 +1796,7 @@
function to a one-time bit of information. The server sends
a small random-ish string to the client; the client uses the
user's password to hash the string; the server then looks to
- see if the hashed value is what it expected.</para>
+ see whether the hashed value is what it expected.</para>
<para>Configuring Apache for Digest authentication is also
fairly easy, and only a small variation on our prior
@@ -1817,19 +1815,18 @@
</Location>
</screen>
- <para>If you're looking for maximum security, then public-key
+ <para>If you're looking for maximum security, public key
cryptography is the best solution. It may be best to use
some sort of SSL encryption, so that clients authenticate
via <literal>https://</literal> instead
of <literal>http://</literal>; at a bare minimum, you can
- configure Apache to use a self-signed server certificate.
- <footnote>
+ configure Apache to use a self-signed server certificate<footnote>
<para>While self-signed server certificates are still
vulnerable to a <quote>man-in-the-middle</quote> attack,
such an attack is much more difficult for a casual
observer to pull off, compared to sniffing unprotected
passwords.</para>
- </footnote>
+ </footnote>.
Consult Apache's documentation (and OpenSSL documentation)
about how to do that.</para>
@@ -1847,7 +1844,7 @@
that kind of unwanted attention less likely to result in
sensitive data leaks.</para>
- <para>If a Subversion client is compiled to use OpenSSL, then
+ <para>If a Subversion client is compiled to use OpenSSL,
it gains the ability to speak to an Apache server via
<literal>https://</literal> URLs. The Neon library used by
the Subversion client is not only able to verify server
@@ -1859,8 +1856,8 @@
<para>It's beyond the scope of this book to describe how to
generate client and server certificates and how to
configure Apache to use them. Many other books, including
- Apache's own documentation, describe this task. But what
- <emphasis>can</emphasis> be covered here is how to manage
+ Apache's own documentation, describe this task. But what we
+ <emphasis>can</emphasis> cover here is how to manage
server and client certificates from an ordinary Subversion
client.</para>
@@ -1877,7 +1874,7 @@
verify that it trusts the certificate: is the server really
who it claims to be? The OpenSSL library does this by
examining the signer of the server certificate, or
- <firstterm>certifying authority</firstterm> (CA). If
+ <firstterm>certifcate authority</firstterm> (CA). If
OpenSSL is unable to automatically trust the CA, or if some
other problem occurs (such as an expired certificate or
hostname mismatch), the Subversion command-line client will
@@ -1902,7 +1899,7 @@
<para>This dialogue should look familiar; it's essentially the
same question you've probably seen coming from your web
browser (which is just another HTTP client like Subversion).
- If you choose the (p)ermanent option, the server certificate
+ If you choose the <literal>(p)</literal>ermanent option, the server certificate
will be cached in your private runtime
<filename>auth/</filename> area in just the same way your
username and password are cached (see <xref
@@ -1937,7 +1934,7 @@
Apache trusts. A client certificate is usually stored on
disk in encrypted format, protected by a local password.
When Subversion receives this challenge, it will ask you for
- both a path to the certificate and for the password that
+ a path to the certificate and the password that
protects it:</para>
<screen>
@@ -1975,12 +1972,11 @@
<literal>ssl-client-cert-file</literal> and
<literal>ssl-client-cert-password</literal> variables, the
Subversion client can automatically respond to a client
- certificate challenge without prompting you.
- <footnote>
+ certificate challenge without prompting you<footnote>
<para>More security-conscious folk might not want to store
the client certificate password in the runtime
<filename>servers</filename> file.</para>
- </footnote>
+ </footnote>.
</para>
</sect3>
@@ -2133,7 +2129,7 @@
<xref linkend="svn.serverconfig.httpd.authz.perdir.ex-1"/>.)</para>
<example id="svn.serverconfig.httpd.authz.perdir.ex-1">
- <title>A sample configuration for anonymous access.</title>
+ <title>A sample configuration for anonymous access</title>
<programlisting>
<Location /repos>
DAV svn
@@ -2154,7 +2150,7 @@
<xref linkend="svn.serverconfig.httpd.authz.perdir.ex-2"/>.)</para>
<example id="svn.serverconfig.httpd.authz.perdir.ex-2">
- <title>A sample configuration for authenticated access.</title>
+ <title>A sample configuration for authenticated access</title>
<programlisting>
<Location /repos>
DAV svn
@@ -2214,8 +2210,8 @@
<para>Once you've settled on one of these three
basic <filename>httpd.conf</filename> templates, you need to
create your file containing access rules for particular
- paths within the repository. This is described later in
- this chapter in
+ paths within the repository. We describe this later in
+ this chapter, in
<xref linkend="svn.serverconfig.pathbasedauthz"/>.</para>
</sect3>
@@ -2227,13 +2223,13 @@
<para>The <command>mod_dav_svn</command> module goes through a
lot of work to make sure that data you've marked
<quote>unreadable</quote> doesn't get accidentally leaked.
- This means that it needs to closely monitor all of the paths
+ This means it needs to closely monitor all of the paths
and file-contents returned by commands such as <command>svn
- checkout</command> or <command>svn update</command>.
+ checkout</command> and <command>svn update</command>.
If these commands encounter a path that isn't
- readable according to some authorization policy, then the
+ readable according to some authorization policy, the
path is typically omitted altogether. In the case of
- history or rename tracing—e.g., running a command such
+ history or rename tracing—for example, running a command such
as <userinput>svn cat -r OLD foo.c</userinput> on a file that
was renamed long ago—the rename tracking will simply
halt if one of the object's former names is determined to be
@@ -2244,7 +2240,7 @@
log</command>. When retrieving a list of revisions, the
server looks at every changed path in each revision and
checks it for readability. If an unreadable path is
- discovered, then it's omitted from the list of the
+ discovered, it's omitted from the list of the
revision's changed paths (normally seen with
the <option>--verbose</option> option), and the whole log
message is suppressed. Needless to say, this can be
@@ -2263,7 +2259,7 @@
sorts, which allows you to trade security features for
speed. If you're not enforcing any sort of per-directory
authorization (i.e., not using
- <command>mod_authz_svn</command> or similar module), then
+ <command>mod_authz_svn</command> or similar module),
you can disable all of this path checking. In your
<filename>httpd.conf</filename> file, use the
<literal>SVNPathAuthz</literal> directive as shown in
@@ -2284,7 +2280,7 @@
<para>The <literal>SVNPathAuthz</literal> directive
is <quote>on</quote> by default. When
- set <quote>off,</quote> all path-based authorization
+ set to <quote>off,</quote> all path-based authorization
checking is disabled;
<command>mod_dav_svn</command> stops invoking authorization
checks on every path it discovers.</para>
@@ -2347,7 +2343,7 @@
PROPFIND requests and understanding DeltaV concepts. This
is something your web browser simply can't do.</para>
- <para>So to answer the question, one obvious way to see
+ <para>So, to answer the question, one obvious way to see
older revisions of files and directories is by passing the
<option>--revision</option> (<option>-r</option>) argument
to the <command>svn list</command> and <command>svn
@@ -2355,10 +2351,9 @@
web browser, however, you can use third-party software. A
good example of this is ViewVC (<ulink
url="http://viewvc.tigris.org/"/>). ViewVC was originally
- written to display CVS repositories through the Web,
- <footnote>
- <para>Back then, it was called <quote>ViewCVS</quote>.</para>
- </footnote>
+ written to display CVS repositories through the Web<footnote>
+ <para>Back then, it was called ViewCVS.</para>
+ </footnote>,
and the latest releases are able to understand Subversion
repositories as well.</para>
</sidebar>
@@ -2383,8 +2378,8 @@
<para>To make this happen, you need only to make sure that
your files have the
- proper <literal>svn:mime-type</literal> set. This is
- discussed in more detail in
+ proper <literal>svn:mime-type</literal> set. We discuss this
+ in more detail in
<xref linkend="svn.advanced.props.special.mime-type"/>,
and you can even configure your client to automatically
attach proper <literal>svn:mime-type</literal> properties
@@ -2394,7 +2389,7 @@
<para>So in our example, if one were to set
the <literal>svn:mime-type</literal> property
to <literal>text/html</literal> on
- file <filename>foo.html</filename>, then Apache would
+ file <filename>foo.html</filename>, Apache would
properly tell your web browser to render the file as HTML.
One could also attach proper <literal>image/*</literal>
mime-type properties to image files and ultimately get an
@@ -2442,7 +2437,7 @@
Keep in mind that the path provided to the
<literal>SVNIndexXSLT</literal> directory is actually a URL
path—browsers need to be able to read your
- stylesheets in order to make use of them!</para>
+ stylesheets to make use of them!</para>
</sect4>
@@ -2482,7 +2477,7 @@
<para>Because Apache is an HTTP server at heart, it contains
fantastically flexible logging features. It's beyond the
- scope of this book to discuss all ways logging can be
+ scope of this book to discuss all of the ways logging can be
configured, but we should point out that even the most
generic <filename>httpd.conf</filename> file will cause
Apache to produce two logs:
@@ -2524,7 +2519,7 @@
Apache's <literal>CustomLog</literal> directive (which is
explained in more detail in Apache's own documentation).
Be sure to invoke this
- directive <emphasis>outside</emphasis> of your
+ directive <emphasis>outside</emphasis> your
Subversion <literal>Location</literal> block:</para>
<screen>
@@ -2537,18 +2532,18 @@
</screen>
<para>In this example, we're asking Apache to create a special
- logfile <filename>svn_logfile</filename> in the standard
+ logfile, <filename>svn_logfile</filename>, in the standard
Apache <filename>logs</filename> directory.
The <literal>%t</literal> and <literal>%u</literal>
variables are replaced by the time and username of the
- request, respectively. The really important part are the
+ request, respectively. The really important parts are the
two instances of <literal>SVN-ACTION</literal>.
When Apache sees that variable, it substitutes the value of
the <literal>SVN-ACTION</literal> environment variable,
which is automatically set by <command>mod_dav_svn</command>
whenever it detects a high-level client action.</para>
- <para>So instead of having to interpret a
+ <para>So, instead of having to interpret a
traditional <filename>access_log</filename> like
this:</para>
@@ -2562,7 +2557,7 @@
…
</screen>
- <para>you can instead peruse a much more
+ <para>you can peruse a much more
intelligible <filename>svn_logfile</filename> like
this:</para>
@@ -2586,7 +2581,7 @@
Subversion server is that it can be set up for simple
replication. For example, suppose that your team is
distributed across four offices around the globe. The
- Subversion repository can only exist in one of those
+ Subversion repository can exist only in one of those
offices, which means the other three offices will not enjoy
accessing it—they're likely to experience
significantly slower traffic and response times when
@@ -2594,7 +2589,7 @@
up a system consisting of one <firstterm>master</firstterm>
Apache server and several <firstterm>slave</firstterm>
Apache servers. If you place a slave server in each office,
- then users can check out a working copy from whichever slave
+ users can check out a working copy from whichever slave
is closest to them. All read requests go to their local
slave. Write requests get automatically routed to the
single master server. When the commit completes, the master
@@ -2609,7 +2604,7 @@
server, it's a huge win.</para>
<para>In this section, we'll walk you through a standard setup
- of this single-master/multiple slave system. However, keep
+ of this single-master/multiple-slave system. However, keep
in mind that your servers must be running at least Apache
2.2.0 (with <command>mod_proxy</command> loaded) and
Subversion 1.5 (<command>mod_dav_svn</command>).</para>
@@ -2694,7 +2689,7 @@
standard procedure for being on the receiving end of
<command>svnsync</command>.) Then log into the master
server and configure each of the slave repository URIs to
- receive data from the master repository on local
+ receive data from the master repository on the local
disk:</para>
<screen>
@@ -2750,11 +2745,11 @@
<para>The extra bits on the end of each line aren't
necessary, but they're a sneaky way to allow the sync
- commands to run in the background, so that the Subversion
+ commands to run in the background so that the Subversion
client isn't left waiting forever for the commit to
finish. In addition to this
<filename>post-commit</filename> hook, you'll need a
- <filename>post-revprop-change</filename> hook as well, so
+ <filename>post-revprop-change</filename> hook as well so
that when a user, say, modifies a log message, the slave
servers get that change also:</para>
@@ -2791,7 +2786,7 @@
<title>Caveats</title>
<para>Your master/slave replication system should now be
- ready to use. A couple words of warning are in order,
+ ready to use. A couple of words of warning are in order,
however. Remember that this replication isn't entirely
robust in the face of computer or network crashes. For
example, if one of the automated
@@ -2799,7 +2794,7 @@
some reason, the slaves will begin to fall behind. For
example, your remote users will see that they've committed
revision 100, but then when they run <command>svn
- update</command>, their local server will tell them than
+ update</command>, their local server will tell them that
revision 100 doesn't yet exist! Of course, the problem
will be automatically fixed the next time another commit
happens and the subsequent <command>svnsync</command> is
@@ -2810,15 +2805,14 @@
wrong.</para>
<sidebar>
- <title>Can We Set up Replication with
- <command>svnserve</command>?</title>
+ <title>Can We Set Up Replication with svnserve?</title>
<para>If you're using <command>svnserve</command> instead
of Apache as your server, you can certainly configure
your repository's hook scripts to invoke
<command>svnsync</command> as we've shown here, thereby
causing automatic replication from master to slaves.
- Unfortunately, at the time of writing there is no way to
+ Unfortunately, at the time of this writing there is no way to
make slave <command>svnserve</command> servers
automatically proxy write requests back to the master
server. This means your users would only be able to
@@ -2840,9 +2834,9 @@
<para>Several of the features already provided by Apache in
its role as a robust web server can be leveraged for
increased functionality or security in Subversion as well.
- The Subversion client is able to use SSL (the Secure Socket
+ The Subversion client is able to use SSL (the Secure Sockets
Layer, discussed earlier). If your Subversion client is
- built to support SSL, then it can access your Apache server
+ built to support SSL, it can access your Apache server
using <literal>https://</literal> and enjoy a high-quality
encrypted network session.</para>
@@ -2862,7 +2856,7 @@
complicated topic, but also wondrous when implemented. For
details, read <xref linkend="svn.webdav"/>.</para>
- <para>Note that there are number of other small tweaks one can
+ <para>Note that there are a number of other small tweaks one can
make to <command>mod_dav_svn</command> that are too obscure
to mention in this chapter. For a complete list of
all <filename>httpd.conf</filename> directives
@@ -2899,13 +2893,13 @@
the <filename>httpd.conf</filename> file) pointing to your own
rules file. (For a full explanation, see
<xref linkend="svn.serverconfig.httpd.authz.perdir"/>.) If
- you're using <command>svnserve</command>, then you need to make
+ you're using <command>svnserve</command>, you need to make
the <literal>authz-db</literal> variable
(within <filename>svnserve.conf</filename>) point to your
rules file.</para>
<sidebar>
- <title>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
@@ -2936,22 +2930,21 @@
maintain.</para>
<para>Remember that this is a version control system! Even if
- somebody accidentally commits a change to something they
+ somebody accidentally commits a change to something she
shouldn't, it's easy to undo the change. And if a user
- commits to the wrong place with deliberate malice, then it's a
+ commits to the wrong place with deliberate malice, it's a
social problem anyway, and that the problem needs to be dealt
- with outside of Subversion.</para>
+ with outside Subversion.</para>
- <para>So before you begin restricting users' access rights, ask
- yourself if there's a real, honest need for this, or if it's
+ <para>So, before you begin restricting users' access rights, ask
+ yourself whether there's a real, honest need for this, or whether it's
just something that <quote>sounds good</quote> to an
administrator. Decide whether it's worth sacrificing some
- server speed for, and remember that there's very little risk
+ server speed, and remember that there's very little risk
involved; it's bad to become dependent on technology as a
- crutch for social problems.
- <footnote>
+ crutch for social problems<footnote>
<para>A common theme in this book!</para>
- </footnote>
+ </footnote>.
</para>
<para>As an example to ponder, consider that the Subversion
@@ -2981,16 +2974,16 @@
(read/write). If the user is not mentioned at all, no access is
allowed.</para>
- <para>To be more specific: the value of the section names are
- either of the form <literal>[repos-name:path]</literal> or the
+ <para>To be more specific: the value of the section names is
+ either of the form <literal>[repos-name:path]</literal> or of the
form <literal>[path]</literal>. If you're using the
- <literal>SVNParentPath</literal> directive, then it's important
+ <literal>SVNParentPath</literal> directive, it's important
to specify the repository names in your sections. If you omit
- them, then a section such as
+ them, a section such as
<literal>[/some/dir]</literal> will match the path
<filename>/some/dir</filename> in <emphasis>every</emphasis>
repository. If you're using the <literal>SVNPath</literal>
- directive, however, then it's fine to only define paths in your
+ directive, however, it's fine to only define paths in your
sections—after all, there's only one repository.</para>
<screen>
@@ -3007,7 +3000,7 @@
are blocked from accessing this directory.</para>
<para>Of course, permissions are inherited from parent to child
- directory. That means that we can specify a subdirectory with a
+ directory. That means we can specify a subdirectory with a
different access policy for Sally:</para>
<screen>
@@ -3048,7 +3041,7 @@
always matches first. The server tries to match the path
itself, and then the parent of the path, then the parent of
that, and so on. The net effect is that mentioning a specific
- path in the accessfile will always override any permissions
+ path in the access file will always override any permissions
inherited from parent directories.</para>
</tip>
@@ -3064,9 +3057,9 @@
* = r
</screen>
- <para>This is a common setup; notice that there's no repository
- name mentioned in the section name. This makes all repositories
- world-readable to all users. Once all users have read-access to
+ <para>This is a common setup; notice that no repository
+ name is mentioned in the section name. This makes all repositories
+ world-readable to all users. Once all users have read access to
the repositories, you can give explicit
<literal>rw</literal> permission to certain users on specific
subdirectories within specific repositories.</para>
@@ -3078,7 +3071,7 @@
of anonymous and authenticated access, all users start out
accessing anonymously. The server looks for a
<literal>*</literal> value defined for the path being accessed;
- if it can't find one, then it demands real authentication from
+ if it can't find one, it demands real authentication from
the client.</para>
<para>The access file also allows you to define whole groups of
@@ -3126,7 +3119,7 @@
file syntax: username aliases. Some authentication systems
expect and carry relatively short usernames of the sorts we've
been describing here—<literal>harry</literal>,
- <literal>sally</literal>, <literal>joe</literal>, etc. But
+ <literal>sally</literal>, <literal>joe</literal>, and so on. But
other authentication systems—such as those which use LDAP
stores or SSL client certificates—may carry much more
complex usernames. For example, Harry's username in an
@@ -3134,8 +3127,8 @@
Hacker,OU=Engineers,DC=red-bean,DC=com</literal>. With
usernames like that, the access file can become quite bloated
with long or obscure usernames that are easy to mistype.
- Fortunately, username aliases allow you to only have to type the
- correct complex username once, in a statement which assigns to
+ Fortunately, username aliases allow you to have to type the
+ correct complex username only once, in a statement which assigns to
it a more easily digestable alias.</para>
<screen>
@@ -3173,7 +3166,7 @@
<para>If you're using Apache as your Subversion server and have
made certain subdirectories of your repository unreadable to
- certain users, then you need to be aware of a possible
+ certain users, you need to be aware of a possible
nonoptimal behavior with <command>svn checkout</command>.</para>
<para>When the client requests a checkout or update over HTTP, it
@@ -3181,16 +3174,16 @@
large) server response. When the server receives the request,
that is the <emphasis>only</emphasis> opportunity Apache has to
demand user authentication. This has some odd side effects.
- For example, if a certain subdirectory of the repository is only
- readable by user Sally, and user Harry checks out a parent
+ For example, if a certain subdirectory of the repository is
+ readable only by user Sally, and user Harry checks out a parent
directory, his client will respond to the initial authentication
challenge as Harry. As the server generates the large response,
- there's no way it can re-send an authentication challenge when
+ there's no way it can resend an authentication challenge when
it reaches the special subdirectory; thus the subdirectory is
skipped altogether, rather than asking the user to
- re-authenticate as Sally at the right moment. In a similar way,
+ reauthenticate as Sally at the right moment. In a similar way,
if the root of the repository is anonymously world-readable,
- then the entire checkout will be done without
+ the entire checkout will be done without
authentication—again, skipping the unreadable directory,
rather than asking for authentication partway through.</para>
</sidebar>
@@ -3237,7 +3230,7 @@
<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
+ user) in the preceding 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
@@ -3282,7 +3275,7 @@
<para>Once you've jumped through these hoops, your repository
should be accessible by all the necessary processes. It may
seem a bit messy and complicated, but the problems of having
- multiple users sharing write-access to common files are classic
+ multiple users sharing write access to common files are classic
ones that are not often elegantly solved.</para>
<para>Fortunately, most repository administrators will never
@@ -3292,10 +3285,10 @@
access URLs—they can typically contact the Apache HTTP
server or <command>svnserve</command> using
<literal>localhost</literal> for the server name in their
- <literal>http://</literal> or <literal>svn://</literal> URLs.
+ <literal>http://</literal> or <literal>svn://</literal> URL.
And maintaining multiple server processes for your Subversion
repositories is likely to be more of a headache than necessary.
- We recommend you choose a single server that best meets your
+ We recommend that you choose a single server that best meets your
needs and stick with it!</para>
<sidebar>
@@ -3305,7 +3298,7 @@
existing SSH accounts to share a repository without
permissions problems. If you're confused about all the things
that you (as an administrator) need to do on a Unix-like
- system, here's a quick checklist that resummarizes some of
+ system, here's a quick checklist that resummarizes some of the
topics discussed in this section:</para>
<itemizedlist>
@@ -3325,7 +3318,7 @@
</listitem>
<listitem>
<para>Your users need to use a sane umask when accessing the
- repository, so make sure that <command>svnserve</command>
+ repository, so make sure <command>svnserve</command>
(<filename>/usr/bin/svnserve</filename>, or wherever it
lives in <literal>$PATH</literal>) is actually a wrapper
script that runs <userinput>umask 002</userinput> and
More information about the svnbook-dev
mailing list