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

cmpilato noreply at red-bean.com
Sat Mar 29 01:53:04 CDT 2008


Author: cmpilato
Date: Sat Mar 29 01:53:03 2008
New Revision: 3007

Log:
Enter Chapter 5's O'Reilly copyedits.

Modified:
   trunk/src/en/book/ch05-repository-admin.xml

Modified: trunk/src/en/book/ch05-repository-admin.xml
==============================================================================
--- trunk/src/en/book/ch05-repository-admin.xml	(original)
+++ trunk/src/en/book/ch05-repository-admin.xml	Sat Mar 29 01:53:03 2008
@@ -6,7 +6,7 @@
     all the love and attention an administrator can offer.  While the
     repository is generally a low-maintenance item, it is important to
     understand how to properly configure and care for it so that
-    potential problems are avoided, and actual problems are safely
+    potential problems are avoided, and so actual problems are safely
     resolved.</para>
 
   <para>In this chapter, we'll discuss how to create and configure a
@@ -14,7 +14,7 @@
     maintenance, providing examples of how and when to use the
     <command>svnlook</command> and <command>svnadmin</command> tools
     provided with Subversion.  We'll address some common questions and
-    mistakes, and give some suggestions on how to arrange the data in
+    mistakes and give some suggestions on how to arrange the data in
     the repository.</para>
 
   <para>If you plan to access a Subversion repository only in the
@@ -79,7 +79,8 @@
       <varlistentry>
         <term>dav</term>
         <listitem>
-          <para>A directory provided to mod_dav_svn for its private
+          <para>A directory provided to
+            <filename>mod_dav_svn</filename> for its private
             housekeeping data.</para>
         </listitem>
       </varlistentry>
@@ -144,7 +145,7 @@
       creating and configuring a repository are fairly straightforward
       tasks.  There are a few preliminary decisions you'll want to
       make, but the actual work involved in any given setup of a
-      Subversion repository is pretty straightforward, tending towards
+      Subversion repository is pretty basic, tending towards
       mindless repetition if you find yourself setting up multiples of
       these things.</para>
 
@@ -198,10 +199,10 @@
       <para>There are benefits to using a single repository for
         multiple projects, most obviously the lack of duplicated
         maintenance.  A single repository means that there is one set
-        of hook programs, one thing to routinely backup, one thing to
+        of hook programs, one thing to routinely back up, one thing to
         dump and load if Subversion releases an incompatible new
         version, and so on.  Also, you can move data between projects
-        easily, and without losing any historical versioning
+        easily, without losing any historical versioning
         information.</para>
 
       <para>The downside of using a single repository is that
@@ -247,19 +248,19 @@
         Subversion community recommends that you choose a repository
         location for each <firstterm>project
         root</firstterm>—the <quote>top-most</quote> directory
-        which contains data related to that project—and then
+        that contains data related to that project—and then
         create three subdirectories beneath that root:
         <filename>trunk</filename>, meaning the directory under which
         the main project development occurs;
         <filename>branches</filename>, which is a directory in which
         to create various named branches of the main development line;
-        <filename>tags</filename>, which is a collection of tree
+        and <filename>tags</filename>, which is a collection of tree
         snapshots that are created, and perhaps destroyed, but never
         changed.
         <footnote>
           <para>The <filename>trunk</filename>, <filename>tags</filename>, 
             and <filename>branches</filename> trio are sometimes referred
-            to as <quote>the TTB directories</quote>.</para>
+            to as <quote>the TTB directories.</quote></para>
         </footnote>
         </para>
 
@@ -347,7 +348,7 @@
 
       <para>There's nothing particularly incorrect about such a
         layout, but it may or may not seem as intuitive for your
-        users.  Especially in large, multi-project situations with
+        users.  Especially in large, multiproject situations with
         many users, those users may tend to be familiar with only one
         or two of the projects in the repository.  But the
         projects-as-branch-siblings tends to de-emphasize project
@@ -373,7 +374,7 @@
         Subversion server or directly), by whom (users behind your
         corporate firewall or the whole world out on the open
         Internet), what other services you'll be providing around
-        Subversion (repository browsing interfaces, e-mail based
+        Subversion (repository browsing interfaces, email-based
         commit notification, etc.), your data backup strategy, and so
         on.</para>
 
@@ -385,14 +386,14 @@
         certain deployment scenarios might require accessing the
         repository via a remote filesystem from multiple computers, in
         which case (as you'll read in the next section) your choice of
-        a repository back-end data store turns out not to be a choice
-        at all because only one of the available back-ends will work
+        a repository backend data store turns out not to be a choice
+        at all because only one of the available backends will work
         in this scenario.</para>
 
       <para>Addressing each possible way to deploy
-        Subversion is both impossible, and outside the scope of this
+        Subversion is both impossible and outside the scope of this
         book.  We simply encourage you to evaluate your options using
-        these pages and other sources as your reference material, and
+        these pages and other sources as your reference material and to
         plan ahead.</para>
 
     </sect2>
@@ -403,20 +404,20 @@
 
       <para>As of version 1.1, Subversion provides two options for the
         type of underlying data store—often referred to as
-        <quote>the back-end</quote> or, somewhat confusingly,
+        <quote>the backend</quote> or, somewhat confusingly,
         <quote>the (versioned) filesystem</quote>—that each
         repository uses.  One type of data store keeps everything in a
         Berkeley DB (or BDB) database environment; repositories that
         use this type are often referred to as being
-        <quote>BDB-backed</quote>.  The other type stores data in
+        <quote>BDB-backed.</quote>  The other type stores data in
         ordinary flat files, using a custom format.  Subversion
         developers have adopted the habit of referring to this latter
         data storage mechanism as <firstterm>FSFS</firstterm>
         <footnote>
-          <para>Often pronounced <quote>fuzz-fuzz</quote>, if Jack
+          <para>Often pronounced <quote>fuzz-fuzz,</quote> if Jack
             Repenning has anything to say about it.  (This book,
             however, assumes that the reader is thinking
-            <quote>eff-ess-eff-ess</quote>.)</para>
+            <quote>eff-ess-eff-ess.</quote>)</para>
         </footnote> 
         —a versioned filesystem implementation that uses the
         native OS filesystem directly—rather than via a database
@@ -427,7 +428,7 @@
         repositories.</para>
 
       <table id="svn.reposadmin.basics.backends.tbl-1">
-        <title>Repository Data Store Comparison</title>
+        <title>Repository data store comparison</title>
         <tgroup cols="4">
           <thead>
             <row>
@@ -441,76 +442,76 @@
             <row>
               <entry morerows="1">Reliability</entry>
               <entry>Data integrity</entry>
-              <entry>when properly deployed, extremely reliable;
-                Berkeley DB 4.4 brings auto-recovery</entry>
-              <entry>older versions had some rarely demonstrated, but
-                data-destroying bugs</entry>
+              <entry>When properly deployed, extremely reliable;
+                Berkeley DB 4.4 brings auto-recovery.</entry>
+              <entry>Older versions had some rarely demonstrated, but
+                data-destroying bugs.</entry>
             </row>
             <row>
               <entry>Sensitivity to interruptions</entry>
-              <entry>very; crashes and permission problems can leave the
-                database <quote>wedged</quote>, requiring journaled
-                recovery procedures</entry>
-              <entry>quite insensitive</entry>
+              <entry>Very; crashes and permission problems can leave the
+                database <quote>wedged,</quote> requiring journaled
+                recovery procedures.</entry>
+              <entry>Quite insensitive.</entry>
             </row>
             <row>
               <entry morerows="3">Accessibility</entry>
               <entry>Usable from a read-only mount</entry>
-              <entry>no</entry>
-              <entry>yes</entry>
+              <entry>No.</entry>
+              <entry>Yes.</entry>
             </row>
             <row>
               <entry>Platform-independent storage</entry>
-              <entry>no</entry>
-              <entry>yes</entry>
+              <entry>No.</entry>
+              <entry>Yes.</entry>
             </row>
             <row>
               <entry>Usable over network filesystems</entry>
-              <entry>generally, no</entry>
-              <entry>yes</entry>
+              <entry>Generally, no.</entry>
+              <entry>Yes.</entry>
             </row>
             <row>
               <entry>Group permissions handling</entry>
-              <entry>sensitive to user umask problems;  best if accessed
-                by only one user</entry>
-              <entry>works around umask problems</entry>
+              <entry>Sensitive to user umask problems; best if accessed
+                by only one user.</entry>
+              <entry>Works around umask problems.</entry>
             </row>
             <row>
               <entry morerows="2">Scalability</entry>
               <entry>Repository disk usage</entry>
-              <entry>larger (especially if logfiles aren't purged)</entry>
-              <entry>smaller</entry>
+              <entry>Larger (especially if logfiles aren't purged).</entry>
+              <entry>Smaller.</entry>
             </row>
             <row>
               <entry>Number of revision trees</entry>
-              <entry>database;  no problems</entry>
-              <entry>some older native filesystems don't scale well with
-                thousands of entries in a single directory</entry>
+              <entry>Database; no problems.</entry>
+              <entry>Some older native filesystems don't scale well with
+                thousands of entries in a single directory.</entry>
             </row>
             <row>
               <entry>Directories with many files</entry>
-              <entry>slower</entry>
-              <entry>faster</entry>
+              <entry>Slower.</entry>
+              <entry>Faster.</entry>
             </row>
             <row>
               <entry morerows="1">Performance</entry>
               <entry>Checking out latest revision</entry>
-              <entry>no meaningful difference</entry>
-              <entry>no meaningful difference</entry>
+              <entry>No meaningful difference.</entry>
+              <entry>No meaningful difference.</entry>
             </row>
             <row>
               <entry>Large commits</entry>
-              <entry>slower overall, but cost is amortized across the
-                lifetime of the commit</entry>
-              <entry>faster overall, but finalization delay may cause 
-                client timeouts</entry>
+              <entry>Slower overall, but cost is amortized across the
+                lifetime of the commit.</entry>
+              <entry>Faster overall, but finalization delay may cause 
+                client timeouts.</entry>
             </row>
           </tbody>
         </tgroup>      
       </table>
 
       <para>There are advantages and disadvantages to each of these
-        two back-end types.  Neither of them is more
+        two backend types.  Neither of them is more
         <quote>official</quote> than the other, though the newer FSFS
         is the default data store as of Subversion 1.2.  Both are
         reliable enough to trust with your versioned data.  But as you
@@ -524,17 +525,17 @@
         system—largely explain why today almost everyone uses
         the FSFS backend when creating new repositories.</para>
 
-      <para>Fortunately, most programs which access Subversion
-        repositories are blissfully ignorant of which back-end data
+      <para>Fortunately, most programs that access Subversion
+        repositories are blissfully ignorant of which backend data
         store is in use.  And you aren't even necessarily stuck with
         your first choice of a data store—in the event that you
         change your mind later, Subversion provides ways of migrating
         your repository's data into another repository that uses a
-        different back-end data store.  We talk more about that later
+        different backend data store.  We talk more about that later
         in this chapter.</para>
 
       <para>The following subsections provide a more detailed look at
-        the available back-end data store types.</para>
+        the available backend data store types.</para>
 
       <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
       <sect3 id="svn.reposadmin.basics.backends.bdb">
@@ -542,7 +543,7 @@
         
         <para>When the initial design phase of Subversion was in
           progress, the developers decided to use Berkeley DB for a
-          variety of reasons, including its open-source license,
+          variety of reasons, including its open source license,
           transaction support, reliability, performance, API
           simplicity, thread-safety, support for cursors, and so
           on.</para>
@@ -563,32 +564,33 @@
           of the database.</para>
 
         <para>Another great feature of Berkeley DB is <firstterm>hot
-          backups</firstterm>—the ability to backup the database
-          environment without taking it <quote>offline</quote>.  We'll
-          discuss how to backup your repository in <xref
-          linkend="svn.reposadmin.maint.backup"/>, but the benefits of being
-          able to make fully functional copies of your repositories
-          without any downtime should be obvious.</para>
+          backups</firstterm>—the ability to back up the
+          database environment without taking it
+          <quote>offline.</quote> We'll discuss how to back up your
+          repository later in this chapter (in <xref
+          linkend="svn.reposadmin.maint.backup"/>), but the benefits
+          of being able to make fully functional copies of your
+          repositories without any downtime should be obvious.</para>
 
         <para>Berkeley DB is also a very reliable database system when
           properly used.  Subversion uses Berkeley DB's logging
           facilities, which means that the database first writes to
-          on-disk log files a description of any modifications it is
+          on-disk logfiles a description of any modifications it is
           about to make, and then makes the modification itself.  This
           is to ensure that if anything goes wrong, the database
           system can back up to a previous
           <firstterm>checkpoint</firstterm>—a location in the
-          log files known not to be corrupt—and replay
+          logfiles known not to be corrupt—and replay
           transactions until the data is restored to a usable state.
-          See <xref linkend="svn.reposadmin.maint.diskspace"/> for
-          more about Berkeley DB log files.</para>
+          See <xref linkend="svn.reposadmin.maint.diskspace"/> later
+          in this chapter for more about Berkeley DB logfiles.</para>
 
         <para>But every rose has its thorn, and so we must note some
           known limitations of Berkeley DB.  First, Berkeley DB
           environments are not portable.  You cannot simply copy a
           Subversion repository that was created on a Unix system onto
           a Windows system and expect it to work.  While much of the
-          Berkeley DB database format is architecture independent,
+          Berkeley DB database format is architecture-independent,
           there are other aspects of the environment that are not.
           Secondly, Subversion uses Berkeley DB in a way that will not
           operate on Windows 95/98 systems—if you need to house
@@ -612,7 +614,7 @@
           in the first place).</para>
 
         <warning>
-          <para>If you attempt to use Berkeley DB on a non-compliant
+          <para>If you attempt to use Berkeley DB on a noncompliant
             remote filesystem, the results are unpredictable—you
             may see mysterious errors right away, or it may be months
             before you discover that your repository database is
@@ -661,9 +663,10 @@
           or <command>svnserve</command> (see <xref
           linkend="svn.serverconfig"/>)—rather than accessing it
           as many different users via <literal>file://</literal> or
-          <literal>svn+ssh://</literal> URLs.  If accessing a Berkeley DB
-          repository directly as multiple users, be sure to read <xref
-          linkend="svn.serverconfig.multimethod"/>.</para>
+          <literal>svn+ssh://</literal> URLs.  If accessing a Berkeley
+          DB repository directly as multiple users, be sure to read
+          <xref linkend="svn.serverconfig.multimethod"/> later in this
+          chapter.</para>
 
       </sect3>
       
@@ -672,7 +675,7 @@
         <title>FSFS</title>
 
         <para>In mid-2004, a second type of repository storage
-          system—one which doesn't use a database at
+          system—one that doesn't use a database at
           all—came into being.  An FSFS repository stores the
           changes associated with a revision in a single file, and so
           all of a repository's revisions can be found in a single
@@ -682,7 +685,7 @@
           into the revisions directory, thus guaranteeing that commits
           are atomic.  And because a revision file is permanent and
           unchanging, the repository also can be backed up while
-          <quote>hot</quote>, just like a BDB-backed
+          <quote>hot,</quote> just like a BDB-backed
           repository.</para>
 
         <para>The FSFS revision files describe a revision's
@@ -708,28 +711,28 @@
           waiting for a response.</para>
 
         <para>The most important distinction, however, is FSFS's
-          imperviousness to <quote>wedging</quote> when something goes
-          wrong.  If a process using a Berkeley DB database runs into
-          a permissions problem or suddenly crashes, the database can
-          be left in an unusable state until an administrator recovers
-          it.  If the same scenarios happen to a process using an FSFS
-          repository, the repository isn't affected at all.  At worst,
-          some transaction data is left behind.</para>
+          imperviousness to wedging when something goes wrong.  If a
+          process using a Berkeley DB database runs into a permissions
+          problem or suddenly crashes, the database can be left in an
+          unusable state until an administrator recovers it.  If the
+          same scenarios happen to a process using an FSFS repository,
+          the repository isn't affected at all.  At worst, some
+          transaction data is left behind.</para>
 
         <para>The only real argument against FSFS is its relative
           immaturity compared to Berkeley DB.  Unlike Berkeley DB,
           which has years of history, its own dedicated development
-          team and, now, Oracle's mighty name attached to it,
+          team, and, now, Oracle's mighty name attached to it,
           <footnote>
             <para>Oracle bought Sleepycat and its flagship software,
               Berkeley DB, on Valentine's Day in 2006.</para>
           </footnote>
-          FSFS is a much newer bit of engineering.  Prior to
-          Subversion 1.4, it was still shaking out some pretty serious
-          data integrity bugs which, while only triggered in very rare
+          FSFS is a newer bit of engineering.  Prior to Subversion
+          1.4, it was still shaking out some pretty serious data
+          integrity bugs, which, while only triggered in very rare
           cases, nonetheless did occur.  That said, FSFS has quickly
-          become the back-end of choice for some of the largest public
-          and private Subversion repositories, and promises a lower
+          become the backend of choice for some of the largest public
+          and private Subversion repositories, and it promises a lower
           barrier to entry for Subversion across the board.</para>
 
       </sect3>
@@ -743,13 +746,13 @@
   <sect1 id="svn.reposadmin.create">
     <title>Creating and Configuring Your Repository</title>
 
-    <para>In <xref linkend="svn.reposadmin.planning" />, we looked at
-      some of the important decisions that should be made before
-      creating and configuring your Subversion repository.  Now, we
-      finally get to get our hands dirty!  In this section, we'll see
-      how to actually create a Subversion repository and configure it
-      to perform custom actions when special repository events
-      occur.</para>
+    <para>Earlier, in <xref linkend="svn.reposadmin.planning" />, we
+      looked at some of the important decisions that should be made
+      before creating and configuring your Subversion repository.
+      Now, we finally get to get our hands dirty!  In this section,
+      we'll see how to actually create a Subversion repository and
+      configure it to perform custom actions when special repository
+      events occur.</para>
 
     <!-- =============================================================== -->
     <sect2 id="svn.reposadmin.basics.creating">
@@ -757,11 +760,13 @@
    
       <para>Subversion repository creation is an incredibly simple
         task.  The <command>svnadmin</command> utility that comes with
-        Subversion provides a subcommand (<literal>create</literal>)
-        for doing just that.</para>
+        Subversion provides a subcommand (<command>svnadmin
+        create</command>) for doing just that.</para>
           
       <screen>
+$ # Create a repository
 $ svnadmin create /var/svn/repos
+$
 </screen>
           
       <para>This creates a new repository in the directory
@@ -819,7 +824,7 @@
           as the configuration files and hook scripts—are meant
           to be examined and modified manually, you shouldn't (and
           shouldn't need to) tamper with the other parts of the
-          repository <quote>by hand</quote>.  The
+          repository <quote>by hand.</quote>  The
           <command>svnadmin</command> tool should be sufficient for
           any changes necessary to your repository, or you can look to
           third-party tools (such as Berkeley DB's tool suite) for
@@ -842,7 +847,7 @@
         repository operation and provide a means by which to both
         report what is about to happen and to prevent it from
         happening at all.  Other hooks (the <quote>post hooks</quote>)
-        run after the completion of a repository event, and are useful
+        run after the completion of a repository event and are useful
         for performing tasks that examine—but don't
         modify—the repository.  Each hook is handed enough
         information to tell what that event is (or was), the specific
@@ -851,25 +856,26 @@
             
       <para>The <filename>hooks</filename> subdirectory is, by
         default, filled with templates for various repository
-        hooks.</para>
+        hooks:</para>
             
       <screen>
 $ ls repos/hooks/
 post-commit.tmpl	  post-unlock.tmpl  pre-revprop-change.tmpl
 post-lock.tmpl		  pre-commit.tmpl   pre-unlock.tmpl
 post-revprop-change.tmpl  pre-lock.tmpl     start-commit.tmpl
+$
 </screen>
             
       <para>There is one template for each hook that the Subversion
-        repository supports, and by examining the contents of those
+        repository supports; by examining the contents of those
         template scripts, you can see what triggers each script
         to run and what data is passed to that script.  Also present
         in many of these templates are examples of how one might use
         that script, in conjunction with other Subversion-supplied
         programs, to perform common useful tasks.  To actually install
         a working hook, you need only place some executable program or
-        script into the <filename>repos/hooks</filename> directory
-        which can be executed as the name (like
+        script into the <filename>repos/hooks</filename> directory,
+        which can be executed as the name (such as
         <command>start-commit</command> or
         <command>post-commit</command>) of the hook.</para>
 
@@ -880,14 +886,14 @@
         files are present for more than just informational
         purposes—the easiest way to install a hook on Unix
         platforms is to simply copy the appropriate template file to a
-        new file that lacks the <literal>.tmpl</literal> extension,
+        new file that lacks the <filename>.tmpl</filename> extension,
         customize the hook's contents, and ensure that the script is
         executable.  Windows, however, uses file extensions to
-        determine whether or not a program is executable, so you would
+        determine whether a program is executable, so you would
         need to supply a program whose basename is the name of the
-        hook, and whose extension is one of the special extensions
+        hook and whose extension is one of the special extensions
         recognized by Windows for executable programs, such as
-        <filename>.exe</filename> for programs, and
+        <filename>.exe</filename> for programs and
         <filename>.bat</filename> for batch files.</para>
 
       <tip>
@@ -903,13 +909,13 @@
       </tip>
 
       <para>Subversion executes hooks as the same user who owns the
-        process which is accessing the Subversion repository.  In most
+        process that is accessing the Subversion repository.  In most
         cases, the repository is being accessed via a Subversion
-        server, so this user is the same user as which that server
+        server, so this user is the same user as whom the server
         runs on the system.  The hooks themselves will need to be
         configured with OS-level permissions that allow that user to
-        execute them.  Also, this means that any file or programs
-        (including the Subversion repository itself) accessed directly
+        execute them.  Also, this means that any programs or files
+        (including the Subversion repository) accessed directly
         or indirectly by the hook will be accessed as the same user.
         In other words, be alert to potential permission-related
         problems that could prevent the hook from performing the tasks
@@ -918,7 +924,7 @@
       <para>There are nine hooks implemented by the Subversion
         repository, and you can get details about each of them in
         <xref linkend="svn.ref.reposhooks" />.  As a repository
-        administrator, you'll need to decide which of hooks you wish
+        administrator, you'll need to decide which hooks you wish
         to implement (by way of providing an appropriately named and
         permissioned hook program), and how.  When you make this
         decision, keep in mind
@@ -944,7 +950,7 @@
           authors should show restraint:  do <emphasis>not</emphasis>
           modify a commit transaction using hook scripts.  While it
           might be tempting to use hook scripts to automatically
-          correct errors or shortcomings or policy violations present
+          correct errors, shortcomings, or policy violations present
           in the files being committed, doing so can cause problems.
           Subversion keeps client-side caches of certain bits of
           repository data, and if you change a commit transaction in
@@ -965,39 +971,39 @@
       <title>Berkeley DB Configuration</title>
 
       <para>A Berkeley DB environment is an encapsulation of one or
-        more databases, log files, region files and configuration
+        more databases, logfiles, region files and configuration
         files.  The Berkeley DB environment has its own set of default
-        configuration values for things like the number of database locks
-        allowed to be taken out at any given time, or the maximum size
-        of the journaling log files, etc.  Subversion's filesystem
-        logic additionally chooses default values for some of the
-        Berkeley DB configuration options.  However, sometimes your
-        particular repository, with its unique collection of data and
-        access patterns, might require a different set of
+        configuration values for things such as the number of database
+        locks allowed to be taken out at any given time, the maximum
+        size of the journaling logfiles, etc.  Subversion's
+        filesystem logic additionally chooses default values for some
+        of the Berkeley DB configuration options.  However, sometimes
+        your particular repository, with its unique collection of data
+        and access patterns, might require a different set of
         configuration option values.</para>
 
       <para>The producers of Berkeley DB understand that different
         applications and database environments have different
-        requirements, and so they have provided a mechanism for
-        overriding at runtime many of the configuration values for the
-        Berkeley DB environment:  BDB checks for the presence of
-        a file named <filename>DB_CONFIG</filename> in the environment
-        directory (namely, the repository's
-        <filename>db</filename> subdirectory), and parses the options found in that file .  Subversion itself creates
-        this file when it creates the rest of the repository.  The
-        file initially contains some default options, as well as
-        pointers to the Berkeley DB online documentation so you can
-        read about what those options do.  Of course, you are free to
-        add any of the supported Berkeley DB options to your
-        <filename>DB_CONFIG</filename> file.  Just be aware that while
-        Subversion never attempts to read or interpret the contents of
-        the file, and makes no direct use of the option settings in
-        it, you'll want to avoid any configuration changes that may
-        cause Berkeley DB to behave in a fashion that is at odds with
-        what Subversion might expect.  Also, changes made to
-        <filename>DB_CONFIG</filename> won't take effect until you
-        recover the database environment (using <command>svnadmin
-        recover</command>).</para>
+        requirements, so they have provided a mechanism for overriding
+        at runtime many of the configuration values for the Berkeley
+        DB environment.  BDB checks for the presence of a file named
+        <filename>DB_CONFIG</filename> in the environment directory
+        (namely, the repository's <filename>db</filename>
+        subdirectory), and parses the options found in that file.
+        Subversion itself creates this file when it creates the rest
+        of the repository.  The file initially contains some default
+        options, as well as pointers to the Berkeley DB online
+        documentation so you can read about what those options do.  Of
+        course, you are free to add any of the supported Berkeley DB
+        options to your <filename>DB_CONFIG</filename> file.  Just be
+        aware that while Subversion never attempts to read or
+        interpret the contents of the file and makes no direct use of
+        the option settings in it, you'll want to avoid any
+        configuration changes that may cause Berkeley DB to behave in
+        a fashion that is at odds with what Subversion might expect.
+        Also, changes made to <filename>DB_CONFIG</filename> won't
+        take effect until you recover the database environment (using
+        <command>svnadmin recover</command>).</para>
 
     </sect2>
   </sect1>
@@ -1009,21 +1015,21 @@
   <sect1 id="svn.reposadmin.maint">
     <title>Repository Maintenance</title>
 
-    <para>Maintaining a Subversion repository can be daunting,
-      mostly due to the complexities inherent in systems which have a
-      database backend.  Doing the task well is all about knowing the
-      tools—what they are, when to use them, and how to use
-      them.  This section will introduce you to the repository
-      administration tools provided by Subversion, and how to wield
-      them to accomplish tasks such as repository data migration,
-      upgrades, backups and cleanups.</para>
+    <para>Maintaining a Subversion repository can be daunting, mostly
+      due to the complexities inherent in systems that have a database
+      backend.  Doing the task well is all about knowing the
+      tools—what they are, when to use them, and how.  This
+      section will introduce you to the repository administration
+      tools provided by Subversion and discuss how to wield them to
+      accomplish tasks such as repository data migration, upgrades,
+      backups and cleanups.</para>
 
     <!-- =============================================================== -->
     <sect2 id="svn.reposadmin.maint.tk">
       <title>An Administrator's Toolkit</title>
 
       <para>Subversion provides a handful of utilities useful for
-        creating, inspecting, modifying and repairing your repository.
+        creating, inspecting, modifying, and repairing your repository.
         Let's look more closely at each of those tools.  Afterward,
         we'll briefly examine some of the utilities included in the
         Berkeley DB distribution that provide functionality specific
@@ -1055,13 +1061,13 @@
 …
 </screen>
 
-        <para>We've already mentioned <command>svnadmin</command>'s
-          <literal>create</literal> subcommand (see <xref
-          linkend="svn.reposadmin.basics.creating"/>).  Most of the
-          others we will cover later
-          in this chapter.  And you can consult <xref
-          linkend="svn.ref.svnadmin" /> for a full rundown of
-          subcommands and what each of them offers.</para>
+        <para>Previously in this chapter (in <xref
+          linkend="svn.reposadmin.basics.creating"/>), we were
+          introduced to the <command>svnadmin create</command>
+          subcommand.  Most of the other <command>svnadmin</command>
+          subcommands we will cover later in this chapter.  And you
+          can consult <xref linkend="svn.ref.svnadmin" /> for a full
+          rundown of subcommands and what each of them offers.</para>
 
       </sect3>
 
@@ -1072,7 +1078,7 @@
         <para><command>svnlook</command> is a tool provided by
           Subversion for examining the various revisions and
           <firstterm>transactions</firstterm> (which are revisions
-          in-the-making) in a repository.  No part of this program
+          in the making) in a repository.  No part of this program
           attempts to change the repository.  <command>svnlook</command>
           is typically used by the repository hooks for reporting the
           changes that are about to be committed (in the case of the
@@ -1095,7 +1101,7 @@
 …
 </screen>
 
-        <para>Nearly every one of <command>svnlook</command>'s
+        <para>Most of <command>svnlook</command>'s
           subcommands can operate on either a revision or a
           transaction tree, printing information about the tree
           itself, or how it differs from the previous revision of the
@@ -1106,7 +1112,7 @@
           both the <option>--revision</option> (<option>-r</option>)
           and <option>--transaction</option> (<option>-t</option>)
           options, <command>svnlook</command> will examine the
-          youngest (or <quote>HEAD</quote>) revision in the
+          youngest (or <literal>HEAD</literal>) revision in the
           repository.  So the following two commands do exactly the
           same thing when 19 is the youngest revision in the
           repository located at
@@ -1117,20 +1123,21 @@
 $ svnlook info /var/svn/repos -r 19
 </screen>
 
-        <para>The only exception to these rules about subcommands is
+        <para>One exception to these rules about subcommands is
           the <command>svnlook youngest</command> subcommand, which
-          takes no options, and simply prints out the repository's
-          youngest revision number.</para>
+          takes no options and simply prints out the repository's
+          youngest revision number:</para>
 
         <screen>
 $ svnlook youngest /var/svn/repos
 19
+$
 </screen>
 
         <note>
           <para>Keep in mind that the only transactions you can browse
             are uncommitted ones.  Most repositories will have no such
-            transactions, because transactions are usually either
+            transactions because transactions are usually either
             committed (in which case, you should access them as
             revision with the <option>--revision</option>
             (<option>-r</option>) option) or aborted and
@@ -1138,8 +1145,8 @@
         </note>
             
         <para>Output from <command>svnlook</command> is designed to be
-          both human- and machine-parsable.  Take as an example the output
-          of the <literal>info</literal> subcommand:</para>
+          both human- and machine-parsable.  Take, as an example, the
+          output of the <command>svnlook info</command> subcommand:</para>
 
         <screen>
 $ svnlook info /var/svn/repos
@@ -1148,10 +1155,11 @@
 27
 Added the usual
 Greek tree.
+$
 </screen>
 
-        <para>The output of the <literal>info</literal> subcommand is
-          defined as:</para>
+        <para>The output of <command>svnlook info</command> consists
+          of the following, in the order given:</para>
 
         <orderedlist>
           <listitem>
@@ -1169,7 +1177,7 @@
           </listitem>
         </orderedlist>
 
-        <para>This output is human-readable, meaning items like the
+        <para>This output is human-readable, meaning items such as the
           datestamp are displayed using a textual representation
           instead of something more obscure (such as the number of
           nanoseconds since the Tasty Freeze guy drove by).  But the
@@ -1221,11 +1229,12 @@
 </screen>
 
         <para>There are only two interesting subcommands:
-          <literal>exclude</literal> and <literal>include</literal>.
-          They allow you to make the choice between implicit or
-          explicit inclusion of paths in the stream.  You can learn
-          more about these subcommands and
-          <command>svndumpfilter</command>'s unique purpose in <xref
+          <command>svndumpfilter exclude</command> and
+          <command>svndumpfilter include</command>.  They allow you to
+          make the choice between implicit or explicit inclusion of
+          paths in the stream.  You can learn more about these
+          subcommands and <command>svndumpfilter</command>'s unique
+          purpose later in this chapter, in <xref
           linkend="svn.reposadmin.maint.filtering" />.</para>
 
       </sect3>
@@ -1267,9 +1276,9 @@
 $
 </screen>
 
-        <para>We talk more about replication repositories with
-          <command>svnsync</command> in <xref
-          linkend="svn.reposadmin.maint.replication" />.</para>
+        <para>We talk more about replicating repositories with
+          <command>svnsync</command> later in this chapter (see <xref
+          linkend="svn.reposadmin.maint.replication" />).</para>
 
       </sect3>
 
@@ -1283,13 +1292,13 @@
           directory of the Subversion source distribution) is a useful
           performance tuning tool for administrators of FSFS-backed
           Subversion repositories.  FSFS repositories contain files
-          which describe the changes made in a single revision, and
-          files which contain the revision properties associated with
+          that describe the changes made in a single revision, and
+          files that contain the revision properties associated with
           a single revision.  Repositories created in versions of
           Subversion prior to 1.5 keep these files in two
           directories—one for each type of file.  As new
           revisions are committed to the repository, Subversion drops
-          more files into these two directories, and over time, the
+          more files into these two directories—over time, the
           number of these files in each directory can grow to be quite
           large.  This has been observed to cause perfomance problems
           on certain network-based filesystems.</para>
@@ -1303,26 +1312,26 @@
           Subversion when reading from the repository.  The number of
           subdirectories used to house these files is configurable,
           though, and that's where
-          <filename>fsfs-reshard.py</filename> comes in.  This script
+          <command>fsfs-reshard.py</command> comes in.  This script
           reshuffles the repository's file structure into a new
-          arrangement which reflects the requested number of sharding
+          arrangement that reflects the requested number of sharding
           subdirecties.  This is especially useful for converting an
           older Subversion repository into the new Subversion 1.5
           sharded layout (which Subversion will not automatically do
-          for you), or for fine-tuning an already-sharded
+          for you) or for fine-tuning an already sharded
           repository.</para>
 
       </sect3>
 
       <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
       <sect3 id="svn.reposadmin.maint.tk.bdbutil">
-        <title>Berkeley DB Utilities</title>
+        <title>Berkeley DB utilities</title>
 
         <para>If you're using a Berkeley DB repository, then all of
           your versioned filesystem's structure and data live in a set
           of database tables within the <filename>db/</filename>
           subdirectory of your repository.  This subdirectory is a
-          regular Berkeley DB environment directory, and can therefore
+          regular Berkeley DB environment directory and can therefore
           be used in conjunction with any of the Berkeley database
           tools, typically provided as part of the Berkeley DB
           distribution.</para>
@@ -1341,7 +1350,7 @@
         <para>However, there are still a few Berkeley DB utilities
           that you might find useful.  The <command>db_dump</command>
           and <command>db_load</command> programs write and read,
-          respectively, a custom file format which describes the keys
+          respectively, a custom file format that describes the keys
           and values in a Berkeley DB database.  Since Berkeley
           databases are not portable across machine architectures,
           this format is a useful way to transfer those databases from
@@ -1361,7 +1370,7 @@
 
         <para>For more information on the Berkeley DB tool chain,
           visit the documentation section of the Berkeley DB section
-          of Oracle's website, located at <ulink
+          of Oracle's web site, located at <ulink
           url="http://www.oracle.com/technology/documentation/berkeley-db/db/"
           />.</para>
 
@@ -1378,12 +1387,12 @@
         <literal>pre-revprop-change</literal> hook; see <xref
         linkend="svn.reposadmin.create.hooks"/>) to accept changes to
         this log message after the commit is finished, then the user
-        can <quote>fix</quote> her log message remotely using the
-        <command>svn</command> program's <literal>propset</literal>
-        command (see <xref linkend="svn.ref.svn.c.propset"/>).
-        However, because of the potential to lose information forever,
-        Subversion repositories are not, by default, configured to
-        allow changes to unversioned properties—except by an
+        can <quote>fix</quote> her log message remotely using
+        <command>svn propset</command> (see <xref
+        linkend="svn.ref.svn.c.propset"/>).  However, because of the
+        potential to lose information forever, Subversion repositories
+        are not, by default, configured to allow changes to
+        unversioned properties—except by an
         administrator.</para>
 
       <para>If a log message needs to be changed by an administrator,
@@ -1411,7 +1420,7 @@
       <warning>
         <para>Remember, though, that by bypassing the hooks, you are
           likely avoiding such things as email notifications of
-          property changes, backup systems which track unversioned
+          property changes, backup systems that track unversioned
           property changes, and so on.  In other words, be very
           careful about what you are changing, and how you change
           it.</para>
@@ -1449,7 +1458,7 @@
           equal to the size of the original data, it takes up only
           enough space to say, <quote>I look just like this other
           piece of data over here, except for the following couple of
-          changes</quote>.  The result is that most of the repository
+          changes.</quote>  The result is that most of the repository
           data that tends to be bulky—namely, the contents of
           versioned files—is stored at a much smaller size than
           the original <quote>fulltext</quote> representation of that
@@ -1464,7 +1473,7 @@
             single Berkeley DB database file, reducing the size of the
             stored values will not immediately reduce the size of the
             database file itself.  Berkeley DB will, however, keep
-            internal records of unused areas of the database file, and
+            internal records of unused areas of the database file and
             consume those areas first before growing the size of the
             database file.  So while deltification doesn't produce
             immediate space savings, it can drastically slow future
@@ -1490,9 +1499,9 @@
           space.  A fastidious administrator may nonetheless wish to
           remove them.</para>
 
-        <para>You can use <command>svnadmin</command>'s
-          <literal>lstxns</literal> command to list the names of the
-          currently outstanding transactions.</para>
+        <para>You can use the <command>svnadmin lstxns</command>
+          command to list the names of the currently outstanding
+          transactions:</para>
 
         <screen>
 $ svnadmin lstxns myrepos
@@ -1512,9 +1521,9 @@
           removal!  If you do indeed want to remove a transaction, its
           name can be passed to <command>svnadmin rmtxns</command>,
           which will perform the cleanup of the transaction.  In fact,
-          the <literal>rmtxns</literal> subcommand can take its input
+          <command>svnadmin rmtxns</command> can take its input
           directly from the output of
-          <literal>lstxns</literal>!</para>
+          <command>svnadmin lstxns</command>!</para>
 
         <screen>
 $ svnadmin rmtxns myrepos `svnadmin lstxns myrepos`
@@ -1531,7 +1540,7 @@
           repository.</para>
 
         <example id="svn.reposadmin.maint.diskspace.deadtxns.ex-1">
-          <title>txn-info.sh (Reporting Outstanding Transactions)</title>
+          <title>txn-info.sh (reporting outstanding transactions)</title>
 
           <programlisting>
 #!/bin/sh
@@ -1554,7 +1563,7 @@
 
         <para>The output of the script is basically a concatenation of
           several chunks of <command>svnlook info</command> output
-          (see <xref linkend="svn.reposadmin.maint.tk.svnlook"/>), and
+          (see <xref linkend="svn.reposadmin.maint.tk.svnlook"/>) and
           will look something like:</para>
 
         <screen>
@@ -1597,29 +1606,29 @@
         <title>Purging unused Berkeley DB logfiles</title>
 
         <para>Until recently, the largest offender of disk space usage
-          with respect to BDB-backed Subversion repositories was the
-          log files in which Berkeley DB performs its pre-writes
-          before modifying the actual database files.  These files
-          capture all the actions taken along the route of changing
-          the database from one state to another—while the
-          database files, at any given time, reflect a particular state, the log
-          files contain all the many changes along the way <emphasis>between</emphasis>
-          states.  Thus, they can grow and accumulate quite
-          rapidly.</para>
+          with respect to BDB-backed Subversion repositories were the
+          logfiles in which Berkeley DB performs its prewrites before
+          modifying the actual database files.  These files capture
+          all the actions taken along the route of changing the
+          database from one state to another—while the database
+          files, at any given time, reflect a particular state, the
+          logfiles contain all the many changes along the way
+          <emphasis>between</emphasis> states.  Thus, they can grow
+          and accumulate quite rapidly.</para>
 
         <para>Fortunately, beginning with the 4.2 release of Berkeley
           DB, the database environment has the ability to remove its
-          own unused log files automatically.  Any
-          repositories created using an <command>svnadmin</command>
-          which is compiled against Berkeley DB version 4.2 or greater
+          own unused logfiles automatically.  Any
+          repositories created using <command>svnadmin</command>
+          when compiled against Berkeley DB version 4.2 or greater
           will be configured for this automatic log file removal.  If
           you don't want this feature enabled, simply pass the
           <option>--bdb-log-keep</option> option to the
           <command>svnadmin create</command> command.  If you forget
-          to do this, or change your mind at a later time, simply edit
+          to do this or change your mind at a later time, simply edit
           the <filename>DB_CONFIG</filename> file found in your
           repository's <filename>db</filename> directory, comment out
-          the line which contains the <literal>set_flags
+          the line that contains the <literal>set_flags
           DB_LOG_AUTOREMOVE</literal> directive, and then run
           <command>svnadmin recover</command> on your repository to
           force the configuration changes to take effect.  See <xref
@@ -1627,16 +1636,16 @@
           database configuration.</para>
 
         <para>Without some sort of automatic log file removal in
-          place, log files will accumulate as you use your repository.
+          place, logfiles will accumulate as you use your repository.
           This is actually somewhat of a feature of the database
           system—you should be able to recreate your entire
-          database using nothing but the log files, so these files can
+          database using nothing but the logfiles, so these files can
           be useful for catastrophic database recovery.  But
-          typically, you'll want to archive the log files that are no
+          typically, you'll want to archive the logfiles that are no
           longer in use by Berkeley DB, and then remove them from disk
           to conserve space.  Use the <command>svnadmin
           list-unused-dblogs</command> command to list the unused
-          log files:</para>
+          logfiles:</para>
 
         <screen>
 $ svnadmin list-unused-dblogs /var/svn/repos
@@ -1649,16 +1658,16 @@
 </screen>
 
         <warning>
-          <para>BDB-backed repositories whose log files are used
-            as part of a backup or disaster recovery plan should
+          <para>BDB-backed repositories whose logfiles are used as
+            part of a backup or disaster recovery plan should
             <emphasis>not</emphasis> make use of the log file
             autoremoval feature.  Reconstruction of a repository's
-            data from log files can only be accomplished when <emphasis>all</emphasis> the log
-            files are available.  If some of the log files are
-            removed from disk before the backup system has a chance to
-            copy them elsewhere, the incomplete set of backed-up log
-            files is essentially useless.</para>
-        </warning>
+            data from logfiles can only be accomplished when
+            <emphasis>all</emphasis> the logfiles are available.  If
+            some of the logfiles are removed from disk before the
+            backup system has a chance to copy them elsewhere, the
+            incomplete set of backed-up log files is essentially
+            useless.</para> </warning>
 
       </sect3>
 
@@ -1670,7 +1679,7 @@
 
       <para>As mentioned in <xref
         linkend="svn.reposadmin.basics.backends.bdb"/>, a Berkeley DB
-        repository can sometimes be left in frozen state if not closed
+        repository can sometimes be left in a frozen state if not closed
         properly.  When this happens, an administrator needs to rewind
         the database back into a consistent state.  This is unique to
         BDB-backed repositories, though—if you are using
@@ -1701,18 +1710,18 @@
       <para>In the course of using your Subversion repository, fatal
         errors or interruptions can prevent a process from having the
         chance to remove the locks it has placed in the database.  The
-        result is that the back-end database system gets
-        <quote>wedged</quote>.  When this happens, any attempts to
+        result is that the backend database system gets
+        <quote>wedged.</quote>  When this happens, any attempts to
         access the repository hang indefinitely (since each new
         accessor is waiting for a lock to go away—which isn't
         going to happen).</para>
 
       <para>If this happens to your repository, don't panic.  The
         Berkeley DB filesystem takes advantage of database
-        transactions and checkpoints and pre-write journaling to
+        transactions, checkpoints, and prewrite journaling to
         ensure that only the most catastrophic of events
         <footnote>
-          <para>E.g.:  hard drive + huge electromagnet = disaster.</para>
+          <para>e.g., hard drive + huge electromagnet = disaster</para>
         </footnote>
         can permanently destroy a database environment.  A
         sufficiently paranoid repository administrator will have made
@@ -1726,8 +1735,8 @@
         <listitem>
           <para>Make sure that there are no processes accessing (or
             attempting to access) the repository.  For networked
-            repositories, this means shutting down the Apache HTTP
-            Server or svnserve daemon, too.</para>
+            repositories, this also means shutting down the Apache HTTP
+            Server or svnserve daemon.</para>
         </listitem>
         <listitem> 
           <para>Become the user who owns and manages the repository.
@@ -1735,7 +1744,7 @@
             running as the wrong user can tweak the permissions of the
             repository's files in such a way that your repository will
             still be inaccessible even after it is 
-            <quote>unwedged</quote>.</para>
+            <quote>unwedged.</quote></para>
         </listitem>
         <listitem>
           <para>Run the command <command>svnadmin recover
@@ -1757,7 +1766,7 @@
       </orderedlist>
             
       <para>This procedure fixes almost every case of repository
-        lock-up.  Make sure that you run this command as the user that
+        wedging.  Make sure that you run this command as the user that
         owns and manages the database, not just as
         <literal>root</literal>.  Part of the recovery process might
         involve recreating from scratch various database files (shared
@@ -1773,7 +1782,7 @@
         (perhaps by renaming it to something like
         <filename>repos.BROKEN</filename>) and then restore your
         latest backup of it.  Then, send an email to the Subversion
-        user list (at <email>users at subversion.tigris.org</email>)
+        users mailing list (at <email>users at subversion.tigris.org</email>)
         describing your problem in detail.  Data integrity is an
         extremely high priority to the Subversion developers.</para>
 
@@ -1791,17 +1800,18 @@
         moved into another repository.</para>
 
       <para>Subversion provides such functionality by way of
-        repository dump streams.  A repository dump stream (often
-        referred to as a <quote>dumpfile</quote> when stored as a file
-        on disk) is a portable, flat file format that describes the
-        various revisions in your repository—what was changed,
-        by whom, when, and so on.  This dump stream is the primary
-        mechanism used to marshal versioned history—in whole or
-        in part, with or without modification—between
-        repositories.  And Subversion provides the tools necessary for
-        creating and loading these dump streams—the
-        <command>svnadmin dump</command> and <command>svnadmin
-        load</command> subcommands, respectively.</para>
+        <firstterm>repository dump streams</firstterm>.  A repository
+        dump stream (often referred to as a <quote>dumpfile</quote>
+        when stored as a file on disk) is a portable, flat file format
+        that describes the various revisions in your
+        repository—what was changed, by whom, when, and so on.
+        This dump stream is the primary mechanism used to marshal
+        versioned history—in whole or in part, with or without
+        modification—between repositories.  And Subversion
+        provides the tools necessary for creating and loading these
+        dump streams: the <command>svnadmin dump</command> and
+        <command>svnadmin load</command> subcommands,
+        respectively.</para>
 
       <warning>
         <para>While the Subversion repository dump format contains
@@ -1813,22 +1823,14 @@
           the file by automatically converting line endings.</para>
       </warning>
 
-      <note>
-        <para>The Subversion repository dump format describes
-          versioned repository changes only.  It will not carry any
-          information about uncommitted transactions, user locks on
-          filesystem paths, repository or server configuration
-          customizations (including hook scripts), and so on.</para>
-      </note>
-
       <para>There are many reasons for dumping and loading Subversion
         repository data.  Early in Subversion's life, the most common
         reason was due to the evolution of Subversion itself.  As
         Subversion matured, there were times when changes made to the
-        back-end database schema caused compatibility issues with
+        backend database schema caused compatibility issues with
         previous versions of the repository, so users had to dump
         their repository data using the previous version of
-        Subversion, and load it into a freshly created repository with
+        Subversion and load it into a freshly created repository with
         the new version of Subversion.  Now, these types of schema
         changes haven't occurred since Subversion's 1.0 release, and
         the Subversion developers promise not to force users to dump
@@ -1837,10 +1839,18 @@
         are still other reasons for dumping and loading, including
         re-deploying a Berkeley DB repository on a new OS or CPU
         architecture, switching between the Berkeley DB and FSFS
-        back-ends, or (as we'll cover in <xref
+        backends, or (as we'll cover later in <xref
         linkend="svn.reposadmin.maint.filtering" />) purging versioned
         data from repository history.</para>
 
+      <note>
+        <para>The Subversion repository dump format describes
+          versioned repository changes only.  It will not carry any
+          information about uncommitted transactions, user locks on
+          filesystem paths, repository or server configuration
+          customizations (including hook scripts), and so on.</para>
+      </note>
+
       <para>Whatever your reason for migrating repository history,
         using the <command>svnadmin dump</command> and
         <command>svnadmin load</command> subcommands is
@@ -1876,7 +1886,7 @@
 
       <para>The other subcommand in the pair, <command>svnadmin
         load</command>, parses the standard input stream as a
-        Subversion repository dump file, and effectively replays those
+        Subversion repository dump file and effectively replays those
         dumped revisions into the target repository for that
         operation.  It also gives informative feedback, this time
         using the standard output stream:</para>
@@ -1912,8 +1922,8 @@
 
       <para>The result of a load is new revisions added to a
         repository—the same thing you get by making commits
-        against that repository from a regular Subversion client.  And
-        just as in a commit, you can use hook programs to perform
+        against that repository from a regular Subversion client.
+        Just as in a commit, you can use hook programs to perform
         actions before and after each of the commits made during a
         load process.  By passing the
         <option>--use-pre-commit-hook</option> and
@@ -1945,9 +1955,9 @@
         larger than the repository itself.  That's because by default
         every version of every file is expressed as a full text in the
         dump file.  This is the fastest and simplest behavior, and
-        nice if you're piping the dump data directly into some other
+        it's nice if you're piping the dump data directly into some other
         process (such as a compression program, filtering program, or
-        into a loading process).  But if you're creating a dump file
+        loading process).  But if you're creating a dump file
         for longer-term storage, you'll likely want to save disk space
         by using the <option>--deltas</option> option.  With this
         option, successive revisions of files will be output as
@@ -1959,7 +1969,7 @@
       <para>We mentioned previously that <command>svnadmin
         dump</command> outputs a range of revisions.  Use the
         <option>--revision</option> (<option>-r</option>) option to
-        specify a single revision to dump, or a range of revisions.
+        specify a single revision, or a range of revisions, to dump.
         If you omit this option, all the existing repository revisions
         will be dumped.</para>
 
@@ -1992,7 +2002,7 @@
         the <option>--incremental</option> option when you dump your
         repository, <command>svnadmin</command> will compare the first
         dumped revision against the previous revision in the
-        repository, the same way it treats every other revision that
+        repository—the same way it treats every other revision that
         gets dumped.  It will then output the first revision exactly
         as it does the rest of the revisions in the dump
         range—mentioning only the changes that occurred in that
@@ -2043,7 +2053,7 @@
 $
 </screen>
 
-      <para>Then, make new directories in the repository which will
+      <para>Then, make new directories in the repository that will
         encapsulate the contents of each of the three previous
         repositories:</para>
 
@@ -2090,7 +2100,7 @@
       <para>Since Subversion stores your versioned history using, at
         the very least, binary differencing algorithms and data
         compression (optionally in a completely opaque database
-        system), attempting manual tweaks is unwise, if not quite
+        system), attempting manual tweaks is unwise if not quite
         difficult, and at any rate strongly discouraged.  And once
         data has been stored in your repository, Subversion
         generally doesn't provide an easy way to remove that data.
@@ -2105,7 +2115,7 @@
         reason).
         <footnote>
           <para>Conscious, cautious removal of certain bits of
-            versioned data is actually supported by real use-cases.
+            versioned data is actually supported by real use cases.
             That's why an <quote>obliterate</quote> feature has been
             one of the most highly requested Subversion features,
             and one which the Subversion developers hope to soon
@@ -2113,33 +2123,30 @@
         </footnote>
         Or, perhaps you have multiple projects sharing a
         single repository, and you decide to split them up into
-        their own repositories.  To accomplish tasks like this,
+        their own repositories.  To accomplish tasks such as these,
         administrators need a more manageable and malleable
         representation of the data in their repositories—the
         Subversion repository dump format.</para>
 
-      <para>As we described in <xref
-        linkend="svn.reposadmin.maint.migrate" />, the
-        Subversion repository dump format is a human-readable
-        representation of the changes that you've made to your
-        versioned data over time.  You use the <command>svnadmin
-        dump</command> command to generate the dump data, and
-        <command>svnadmin load</command> to populate a new
-        repository with it (see <xref
-        linkend="svn.reposadmin.maint.migrate"/>).  The great thing
-        about the human-readability aspect of the dump format is
-        that, if you aren't careless about it, you can manually
-        inspect and modify it.  Of course, the downside is that if
-        you have three years' worth of repository activity
-        encapsulated in what is likely to be a very large dump file,
-        it could take you a long, long time to manually inspect and
-        modify it.</para>
+      <para>As we described earlier in <xref
+        linkend="svn.reposadmin.maint.migrate" />, the Subversion
+        repository dump format is a human-readable representation of
+        the changes that you've made to your versioned data over time.
+        Use the <command>svnadmin dump</command> command to generate
+        the dump data, and <command>svnadmin load</command> to
+        populate a new repository with it.  The great thing about the
+        human-readability aspect of the dump format is that, if you
+        aren't careless about it, you can manually inspect and modify
+        it.  Of course, the downside is that if you have three years'
+        worth of repository activity encapsulated in what is likely to
+        be a very large dump file, it could take you a long, long time
+        to manually inspect and modify it.</para>
 
       <para>That's where <command>svndumpfilter</command> becomes
         useful.  This program acts as path-based filter for
         repository dump streams.  Simply give it either a list of
-        paths you wish to keep, or a list of paths you wish to not
-        keep, then pipe your repository dump data through this
+        paths you wish to keep or a list of paths you wish to not
+        keep, and then pipe your repository dump data through this
         filter.  The result will be a modified stream of dump data
         that contains only the versioned paths you (explicitly or
         implicitly) requested.</para>
@@ -2153,7 +2160,7 @@
         so on.  But sometimes after new revisions start flying in,
         you rethink your layout and would like to make some changes.
         A common change is the decision to move multiple projects
-        which are sharing a single repository into separate
+        that are sharing a single repository into separate
         repositories for each project.</para>
 
       <para>Our imaginary repository contains three projects:
@@ -2191,8 +2198,8 @@
 </screen>
 
       <para>Next, run that dump file through the filter, each time
-        including only one of our top-level directories, and
-        resulting in three new dump files:</para>
+        including only one of our top-level directories.  This results
+        in three new dump files:</para>
 
       <screen>
 $ svndumpfilter include calc < repos-dumpfile > calc-dumpfile
@@ -2204,22 +2211,22 @@
 $
 </screen>
 
-      <para>At this point, you have to make a decision.  Each of
-        your dump files will create a valid repository,
-        but will preserve the paths exactly as they were in the
-        original repository.  This means that even though you would
-        have a repository solely for your <literal>calc</literal>
-        project, that repository would still have a top-level
-        directory named <filename>calc</filename>.  If you want
-        your <filename>trunk</filename>, <filename>tags</filename>,
-        and <filename>branches</filename> directories to live in the
-        root of your repository, you might wish to edit your
-        dump files, tweaking the <literal>Node-path</literal> and
-        <literal>Node-copyfrom-path</literal> headers to no longer have
-        that first <filename>calc/</filename> path component.  Also,
-        you'll want to remove the section of dump data that creates
-        the <filename>calc</filename> directory.  It will look
-        something like:</para>
+      <para>At this point, you have to make a decision.  Each of your
+        dump files will create a valid repository, but will preserve
+        the paths exactly as they were in the original repository.
+        This means that even though you would have a repository solely
+        for your <literal>calc</literal> project, that repository
+        would still have a top-level directory named
+        <filename>calc</filename>.  If you want your
+        <filename>trunk</filename>, <filename>tags</filename>, and
+        <filename>branches</filename> directories to live in the root
+        of your repository, you might wish to edit your dump files,
+        tweaking the <literal>Node-path</literal> and
+        <literal>Node-copyfrom-path</literal> headers so they no
+        longer have that first <filename>calc/</filename> path
+        component.  Also, you'll want to remove the section of dump
+        data that creates the <filename>calc</filename> directory.  It
+        will look something like the following:</para>
 
       <screen>
 Node-path: calc
@@ -2232,8 +2239,9 @@
       <warning>
         <para>If you do plan on manually editing the dump file to
           remove a top-level directory, make sure that your editor is
-          not set to automatically convert end-of-line characters to the native
-          format (e.g. \r\n to \n), as the content will then not agree
+          not set to automatically convert end-of-line characters to
+          the native format (e.g. <literal>\r\n</literal> to
+          <literal>\n</literal>), as the content will then not agree
           with the metadata.  This will render the dump file
           useless.</para>
       </warning>
@@ -2264,7 +2272,7 @@
       <para>Both of <command>svndumpfilter</command>'s subcommands
         accept options for deciding how to deal with
         <quote>empty</quote> revisions.  If a given revision
-        contained only changes to paths that were filtered out, that
+        contains only changes to paths that were filtered out, that
         now-empty revision could be considered uninteresting or even
         unwanted.  So to give the user control over what to do with
         those revisions, <command>svndumpfilter</command> provides
@@ -2302,7 +2310,7 @@
       </variablelist>
       
       <para>While <command>svndumpfilter</command> can be very
-        useful, and a huge timesaver, there are unfortunately a
+        useful and a huge timesaver, there are unfortunately a
         couple of gotchas.  First, this utility is overly sensitive
         to path semantics.  Pay attention to whether paths in your
         dump file are specified with or without leading slashes.
@@ -2323,12 +2331,12 @@
         usage of leading slashes for some reason,
         <footnote>
           <para>While <command>svnadmin dump</command> has a
-            consistent leading slash policy—to not include
-            them—other programs which generate dump data might
+            consistent leading slash policy (to not include
+            them), other programs that generate dump data might
             not be so consistent.</para>
         </footnote>
         you should probably normalize those paths so they all
-        have, or lack, leading slashes.</para>
+        have, or all lack, leading slashes.</para>
 
       <para>Also, copied paths can give you some trouble.
         Subversion supports copy operations in the repository, where
@@ -2343,7 +2351,7 @@
         files created by the copy—and not represent that
         addition as a copy from a source that won't exist in your
         filtered dump data stream.  But because the Subversion
-        repository dump format only shows what was changed in each
+        repository dump format shows only what was changed in each
         revision, the contents of the copy source might not be
         readily available.  If you suspect that you have any copies
         of this sort in your repository, you might want to rethink
@@ -2361,13 +2369,13 @@
         <filename>trunk/my-project</filename>.  But the resulting
         dump file makes no assumptions about the repository into
         which you plan to load this data.  Specifically, the dump
-        data might begin with the revision which added the
+        data might begin with the revision that added the
         <filename>trunk/my-project</filename> directory, but it will
-        <emphasis>not</emphasis> contain directives which would
+        <emphasis>not</emphasis> contain directives that would
         create the <filename>trunk</filename> directory itself
         (because <filename>trunk</filename> doesn't match the
         include filter).  You'll need to make sure that any
-        directories which the new dump stream expect to exist
+        directories that the new dump stream expects to exist
         actually do exist in the target repository before trying to
         load the stream into that repository.</para>
 
@@ -2389,17 +2397,17 @@
 
       <para>As of version 1.4, Subversion provides a program for
         managing scenarios like
-        these—<command>svnsync</command>.
-        <command>svnsync</command> works by essentially asking the
-        Subversion server to <quote>replay</quote> revisions, one at a
-        time.  It then uses that revision information to mimic a
-        commit of the same to another repository.  Neither repository
-        needs to be locally accessible to machine on which
-        <command>svnsync</command> is running—its parameters are
-        repository URLs, and it does all its work through Subversion's
-        repository access (RA) interfaces.  All it requires is read
-        access to the source repository and read/write access to the
-        destination repository.</para>
+        these—<command>svnsync</command>.  This works by
+        essentially asking the Subversion server to
+        <quote>replay</quote> revisions, one at a time.  It then uses
+        that revision information to mimic a commit of the same to
+        another repository.  Neither repository needs to be locally
+        accessible to the machine on which <command>svnsync</command> is
+        running—its parameters are repository URLs, and it does
+        all its work through Subversion's repository access (RA)
+        interfaces.  All it requires is read access to the source
+        repository and read/write access to the destination
+        repository.</para>
 
       <note>
         <para>When using <command>svnsync</command> against a remote
@@ -2409,12 +2417,12 @@
 
       <para>Assuming you already have a source repository that you'd
         like to mirror, the next thing you need is an empty target
-        repository which will actually serve as that mirror.  This
+        repository that will actually serve as that mirror.  This
         target repository can use either of the available filesystem
-        data-store back-ends (see <xref
+        data-store backends (see <xref
         linkend="svn.reposadmin.basics.backends" />), but it must not
-        yet have any version history in it.  The protocol via which
-        <command>svnsync</command> communicates revision information
+        yet have any version history in it.  The protocol that
+        <command>svnsync</command> uses to communicate revision information
         is highly sensitive to mismatches between the versioned
         histories contained in the source and target repositories.
         For this reason, while <command>svnsync</command> cannot
@@ -2455,14 +2463,14 @@
 
       <tip>
         <para>It's a good idea to implement authorization measures
-          which allow your repository replication process to perform
+          that allow your repository replication process to perform
           its tasks while preventing other users from modifying the
           contents of your mirror repository at all.</para>
       </tip>
 
       <para>Let's walk through the use of <command>svnsync</command>
         in a somewhat typical mirroring scenario.  We'll pepper this
-        discourse with practical recommendations which you are free to
+        discourse with practical recommendations, which you are free to
         disregard if they aren't required by or suitable for your
         environment.</para>
 
@@ -2472,14 +2480,14 @@
         publicly on the Internet, hosted on a different machine than
         the one on which the original Subversion source code
         repository lives.  This remote host has a global configuration
-        which permits anonymous users to read the contents of
+        that permits anonymous users to read the contents of
         repositories on the host, but requires users to authenticate
         in order to modify those repositories.  (Please forgive us for
         glossing over the details of Subversion server configuration
         for the moment—those are covered thoroughly in <xref
         linkend="svn.serverconfig" />.)  And for no other reason than
         that it makes for a more interesting example, we'll be driving
-        the replication process from a third machine, the one which
+        the replication process from a third machine—the one that
         we currently find ourselves using.</para>
 
       <para>First, we'll create the repository which will be our
@@ -2506,7 +2514,7 @@
         <literal>syncuser</literal> will be allowed.</para>
 
       <para>We'll use the repository's hook system both to allow the
-        replication process to do what it needs to do, and to enforce
+        replication process to do what it needs to do and to enforce
         that only it is doing those things.  We accomplish this by
         implementing two of the repository event
         hooks—pre-revprop-change and start-commit.  Our
@@ -2564,7 +2572,12 @@
         <command>svnsync</command> is to register in our target
         repository the fact that it will be a mirror of the source
         repository.  We do this using the <command>svnsync
-        initialize</command> subcommand.</para>
+        initialize</command> subcommand.  The URLs we provide point to
+        the root directories of the target and source repositories,
+        respectively.  In Subversion 1.4, this is required—only
+        full mirroring of repositories is permitted.  In Subversion
+        1.5, though, you can use <command>svnsync</command> to mirror
+        only some subtree of the repository, too.</para>
 
       <screen>
 $ svnsync help init
@@ -2587,34 +2600,26 @@
         pre-revprop-change hook on our mirror repository.</para>
 
       <note>
-        <para>The URLs provided to <command>svnsync</command> must
-          point to the root directories of the target and source
-          repositories, respectively.  The tool does not handle
-          mirroring of repository subtrees.</para>
-      </note>
-
-      <note>
-        <para>In Subversion 1.4, the values
-          given to <command>svnsync</command>'s <option>--username</option> and
+        <para>In Subversion 1.4, the values given to
+          <command>svnsync</command>'s <option>--username</option> and
           <option>--password</option> command-line options were used
           for authentication against both the source and destination
           repositories.  This caused problems when a user's
           credentials weren't exactly the same for both repositories,
-          especially when running in non-interactive
-          mode (with the <option>--non-interactive</option> option)
-          might experience problems.</para>
+          especially when running in noninteractive mode (with the
+          <option>--non-interactive</option> option).</para>
 
         <para>This has been fixed in Subversion 1.5 with the
-          introduction of two new pairs of options.  Use the
+          introduction of two new pairs of options.  Use
           <option>--source-username</option> and
-          <option>--source-password</option> options to provide
-          authentication credentials for the source repository; use
+          <option>--source-password</option> to provide authentication
+          credentials for the source repository; use
           <option>--sync-username</option> and
           <option>--sync-password</option> to provide credentials for
           the destination repository.  (The old
-          <command>--username</command> and
-          <command>--password</command> options still exist for
-          compatibility, but we advise against using them.)</para>
+          <option>--username</option> and <option>--password</option>
+          options still exist for compatibility, but we advise against
+          using them.)</para>
 
       </note>
 
@@ -2625,22 +2630,22 @@
         <footnote>
           <para>Be forewarned that while it will take only a few
             seconds for the average reader to parse this paragraph and
-            the sample output which follows it, the actual time
+            the sample output that follows it, the actual time
             required to complete such a mirroring operation is, shall
             we say, quite a bit longer.</para>
         </footnote>
         The <command>svnsync synchronize</command> subcommand will
         peek into the special revision properties previously stored on
-        the target repository, and determine what repository it is
-        mirroring and that the most recently mirrored revision was
-        revision 0.  Then it will query the source repository and
-        determine what the latest revision in that repository is.
-        Finally, it asks the source repository's server to start
-        replaying all the revisions between 0 and that latest
-        revision.  As <command>svnsync</command> get the resulting
-        response from the source repository's server, it begins
-        forwarding those revisions to the target repository's server
-        as new commits.</para>
+        the target repository, and determine both what repository it
+        is mirroring as well as that the most recently mirrored
+        revision was revision 0.  Then it will query the source
+        repository and determine what the latest revision in that
+        repository is.  Finally, it asks the source repository's
+        server to start replaying all the revisions between 0 and that
+        latest revision.  As <command>svnsync</command> get the
+        resulting response from the source repository's server, it
+        begins forwarding those revisions to the target repository's
+        server as new commits.</para>
 
       <screen>
 $ svnsync help synchronize
@@ -2676,37 +2681,37 @@
         revision, there is first a commit of that revision to the
         target repository, and then property changes follow.  This is
         because the initial commit is performed by (and attributed to)
-        the user <literal>syncuser</literal>, and datestamped with the
-        time as of that revision's creation.  Also, Subversion's
-        underlying repository access interfaces don't provide a
-        mechanism for setting arbitrary revision properties as part of
-        a commit.  So <command>svnsync</command> follows up with an
-        immediate series of property modifications which copy all the
-        revision properties found for that revision in the source
-        repository into the target repository.  This also has the
-        effect of fixing the author and datestamp of the revision
-        to match that of the source repository.</para>
+        the user <literal>syncuser</literal>, and it is datestamped
+        with the time as of that revision's creation.  Also,
+        Subversion's underlying repository access interfaces don't
+        provide a mechanism for setting arbitrary revision properties
+        as part of a commit.  So <command>svnsync</command> follows up
+        with an immediate series of property modifications that copy
+        into the target repository all the revision properties found
+        for that revision in the source repository.  This also has the
+        effect of fixing the author and datestamp of the revision to
+        match that of the source repository.</para>
 
       <para>Also noteworthy is that <command>svnsync</command>
         performs careful bookkeeping that allows it to be safely
         interrupted and restarted without ruining the integrity of the
         mirrored data.  If a network glitch occurs while mirroring a
         repository, simply repeat the <command>svnsync
-        synchronize</command> command and it will happily pick up
+        synchronize</command> command, and it will happily pick up
         right where it left off.  In fact, as new revisions appear in
         the source repository, this is exactly what you to do
-        in order to keep your mirror up-to-date.</para>
+        in order to keep your mirror up to date.</para>
 
       <para>There is, however, one bit of inelegance in the process.
         Because Subversion revision properties can be changed at any
-        time throughout the lifetime of the repository, and don't
-        leave an audit trail that indicates when they were changed,
-        replication processes have to pay special attention to them.
-        If you've already mirrored the first 15 revisions of a
-        repository and someone then changes a revision property on
+        time throughout the lifetime of the repository, and because
+        they don't leave an audit trail that indicates when they were
+        changed, replication processes have to pay special attention
+        to them.  If you've already mirrored the first 15 revisions of
+        a repository and someone then changes a revision property on
         revision 12, <command>svnsync</command> won't know to go back
         and patch up its copy of revision 12.  You'll need to tell it
-        to do so manually by using (or with some additionally tooling
+        to do so manually by using (or with some additional tooling
         around) the <command>svnsync copy-revprops</command>
         subcommand, which simply re-replicates all the revision
         properties for a particular revision or range thereof.</para>
@@ -2729,7 +2734,7 @@
         might wish to have your primary repository push changes to one
         or more blessed mirrors as part of its post-commit and
         post-revprop-change hook implementations.  This would enable
-        the mirror to be up-to-date in as near to realtime as is
+        the mirror to be up to date in as near to real time as is
         likely possible.</para>
 
       <para>Also, while it isn't very commonplace to do so,
@@ -2745,25 +2750,25 @@
         through some hoops to make it happen.  First, you need to
         ensure that both the primary and mirror repositories have the
         same repository UUID (which is not the case by default).  See
-        <xref linkend="svn.reposadmin.maint.uuids" /> for more about
-        managing repository UUIDs.</para>
+        <xref linkend="svn.reposadmin.maint.uuids" /> later in this
+        chapter for more about this.</para>
         
-      <para>Once the two repositories have the same UUID, you can
-        use <command>svn switch --relocate</command> to point your
-        working copy to whichever of the repositories you wish to
-        operate against, a process which is described in <xref
+      <para>Once the two repositories have the same UUID, you can use
+        <command>svn switch --relocate</command> to point your working
+        copy to whichever of the repositories you wish to operate
+        against, a process that is described in <xref
         linkend="svn.ref.svn.c.switch" />.  There is a possible danger
         here, though, in that if the primary and mirror repositories
-        aren't in close synchronization, a working copy up-to-date
+        aren't in close synchronization, a working copy up to date
         with, and pointing to, the primary repository will, if
         relocated to point to an out-of-date mirror, become confused
         about the apparent sudden loss of revisions it fully expects
-        to be present, and throws errors to that effect.  If this
-        occurs, you can relocate your working copy back to the primary
-        repository and then either wait until the mirror repository is
-        up-to-date, or backdate your working copy to a revision you
-        know is present in the sync repository and then retry the
-        relocation.</para>
+        to be present, and it will throw errors to that effect.  If
+        this occurs, you can relocate your working copy back to the
+        primary repository and then either wait until the mirror
+        repository is up to date, or backdate your working copy to a
+        revision you know is present in the sync repository, and then
+        retry the relocation.</para>
 
       <para>Finally, be aware that the revision-based replication
         provided by <command>svnsync</command> is only
@@ -2786,7 +2791,7 @@
         the modern computer, one thing unfortunately rings true with
         crystalline clarity—sometimes, things go very, very
         awry.  Power outages, network connectivity dropouts, corrupt
-        RAM and crashed hard drives are but a taste of the evil that
+        RAM, and crashed hard drives are but a taste of the evil that
         Fate is poised to unleash on even the most conscientious
         administrator.  And so we arrive at a very important
         topic—how to make backup copies of your repository
@@ -2800,11 +2805,11 @@
         a catastrophe.  Usually, it means, quite literally, the
         duplication of the entire repository directory (which includes
         either a Berkeley DB or FSFS environment).  Incremental
-        backups are lesser things, backups of only the portion of the
+        backups are lesser things:  backups of only the portion of the
         repository data that has changed since the previous
         backup.</para>
 
-      <para>As far as full backups go, the naive approach might seem
+      <para>As far as full backups go, the naïve approach might seem
         like a sane one, but unless you temporarily disable all other
         access to your repository, simply doing a recursive directory
         copy runs the risk of generating a faulty backup.  In the case
@@ -2833,7 +2838,7 @@
         linkend="svn.reposadmin.maint.diskspace.bdblogs" />) from the
         original repository upon completion of the copy.  Simply
         provide the <option>--clean-logs</option> option on the
-        command-line.</para>
+        command line.</para>
 
       <screen>
 $ svnadmin hotcopy --clean-logs /var/svn/bdb-repos /var/svn/bdb-repos-backup
@@ -2847,13 +2852,13 @@
         hotcopy</command>, allowing you to keep only the most recent
         configured number of backups of each repository.  It will
         automatically manage the names of the backed-up repository
-        directories to avoid collisions with previous backups, and
+        directories to avoid collisions with previous backups and
         will <quote>rotate off</quote> older backups, deleting them so
         only the most recent ones remain.  Even if you also have an
         incremental backup, you might want to run this program on a
         regular basis.  For example, you might consider using
         <command>hot-backup.py</command> from a program scheduler
-        (such as <command>cron</command> on Unix systems) which will
+        (such as <command>cron</command> on Unix systems), which can
         cause it to run nightly (or at whatever granularity of Time
         you deem safe).</para>
 
@@ -2872,10 +2877,10 @@
         that restoring that data can take a long time—longer
         with each new revision committed to your repository.  Also, as
         is the case with so many of the various backup methods,
-        revision property changes made to already-backed-up revisions
-        won't get picked up by a non-overlapping, incremental dump
-        generation.  For these reasons, we recommend against relying
-        solely on dump-based backup approaches.</para>
+        revision property changes that are made to already backed-up
+        revisions won't get picked up by a nonoverlapping,
+        incremental dump generation.  For these reasons, we recommend
+        against relying solely on dump-based backup approaches.</para>
 
       <para>As you can see, each of the various backup types and
         methods has its advantages and disadvantages.  The easiest is
@@ -2902,7 +2907,7 @@
         falls over.  The primary disadvantage of this method is that
         only the versioned repository data gets
         synchronized—repository configuration files,
-        user-specified repository path locks, and other items which
+        user-specified repository path locks, and other items that
         might live in the physical repository directory but not
         <emphasis>inside</emphasis> the repository's virtual versioned
         filesystem are not handled by svnsync.</para>
@@ -2925,17 +2930,17 @@
         backup.</para>
 
       <para>Generally speaking, only the truly paranoid would need to
-        backup their entire repository, say, every time a commit
+        back up their entire repository, say, every time a commit
         occurred.  However, assuming that a given repository has some
         other redundancy mechanism in place with relatively fine
-        granularity (like per-commit emails or incremental dumps), a
+        granularity (such as per-commit emails or incremental dumps), a
         hot backup of the database might be something that a
         repository administrator would want to include as part of a
         system-wide nightly backup.  It's your data—protect it
         as much as you'd like.</para>
             
       <para>Often, the best approach to repository backups is a
-        diversified one which leverages combinations of the methods
+        diversified one that leverages combinations of the methods
         described here.  The Subversion developers, for example, back
         up the Subversion source code repository nightly using
         <command>hot-backup.py</command> and an offsite
@@ -2950,7 +2955,7 @@
         might not save your hardware from the iron fist of Fate,
         <footnote>
           <para>You know—the collective term for all of her
-            <quote>fickle fingers</quote>.</para>
+            <quote>fickle fingers.</quote></para>
         </footnote>
         it should certainly help you recover from those trying 
         times.</para>
@@ -2980,9 +2985,9 @@
         original so that, in the event that you have to restore that
         backup and replace the live repository, users don't suddenly
         see what looks like a different repository.  When dumping and
-        loading repository history (as described in <xref
+        loading repository history (as described earlier in <xref
         linkend="svn.reposadmin.maint.migrate" />), you get to decide
-        whether or not to apply the UUID encapsulated in the data dump
+        whether to apply the UUID encapsulated in the data dump
         stream to the repository you are loading the data into.  The
         particular circumstance will dictate the correct
         behavior.</para>
@@ -2993,7 +2998,7 @@
         setuuid</command> command.  If you provide this subcommand
         with an explicit UUID, it will validate that the UUID is
         well-formed and then set the repository UUID to that value.
-        If you omit the UUID, a brand new UUID will be generated for
+        If you omit the UUID, a brand-new UUID will be generated for
         your repository.</para>
 
       <screen>
@@ -3054,9 +3059,9 @@
       applications, and so on.</para>
 
     <para>Of course, there's often still more to be done when trying
-      to cleanly affect changes like this.  For example, you might
+      to cleanly affect changes such as this.  For example, you might
       need to update your Subversion server configuration to point to
-      the new location of a relocated repository, or to remove
+      the new location of a relocated repository or to remove
       configuration bits for a now-deleted repository.  If you have
       automated processes that publish information from or about your
       repositories, they may need to be updated.  Hook scripts might
@@ -3088,7 +3093,7 @@
       create, configure, and maintain Subversion repositories.  We've
       introduced you to the various tools that will assist you with
       this task.  Throughout the chapter, we've noted common
-      administration pitfalls, and suggestions for avoiding
+      administration pitfalls and offered suggestions for avoiding
       them.</para>
 
     <para>All that remains is for you to decide what exciting data to




More information about the svnbook-dev mailing list