[PATCH] Various svnbook fixes

√ėyvind A. Holm sunny at sunbase.org
Sat Jul 9 22:05:07 CDT 2005


I’ve had a working copy with lots of small fixes to the book lying 
around for ages, with more small tweaks added over time, so maybe it’s 
about time I pass it on. No word wrapping is done to make the patch 
cleaner. There is no formal log message in this stage of the review, 
it’s much less work to sort that out afterwards when the patch has been 
filtered a bit. It’s only trivial changes anyway. But some explanation 
can be done:

  * CVS hasn’t used RCS as a backend in years.

Index: src/en/book/appa.xml
===================================================================
--- src/en/book/appa.xml	(revision 1533)
+++ src/en/book/appa.xml	(working copy)
@@ -25,7 +25,7 @@
     <title>Revision Numbers Are Different Now</title>
 
     <para>In CVS, revision numbers are per-file.  This is because CVS
-      uses RCS as a backend; each file has a corresponding RCS file in
+      previously used RCS as a backend; each file has a corresponding RCS file in
       the repository, and the repository is roughly laid out according
       to the structure of your project tree.</para>

  * Specify that it’s only Berkeley DB databases which can’t live on a 
    network disk. fsfs should have no problems with it?

Index: src/en/book/ch01.xml
===================================================================
--- src/en/book/ch01.xml	(revision 1533)
+++ src/en/book/ch01.xml	(working copy)
@@ -453,9 +453,11 @@
 
     <para>This command creates a new directory
       <filename>/path/to/repos</filename> which contains a Subversion
-      repository.  Make sure that this directory lives on a local
+      repository.  If you are creating a Berkeley DB repository (i.e.
+      using the <option>--fs-type=bdb</option> option with the
+      <command>svnadmin</command> command), make sure that this directory lives on a local
       disk, <emphasis>not</emphasis> a network share.  This new

  * Avoid wordwrapping.

Index: src/en/book/ch04.xml
===================================================================
--- src/en/book/ch04.xml	(revision 1533)
+++ src/en/book/ch04.xml	(working copy)
[...]
           notice that they're unrelated and first attempt to delete
           the old file, then add the new file;  you would see a
-          <literal>D  foo.c</literal> followed by a <literal>A
-          foo.c</literal>.</para>
+          <literal>D  foo.c</literal> followed by a
+          <literal>A  foo.c</literal>.</para>


e6f635b6d86bb49f223fdfc204e10d91  r1533-tweaks.patch

-- sunny256
-------------- next part --------------
Index: src/en/book/appa.xml
===================================================================
--- src/en/book/appa.xml	(revision 1533)
+++ src/en/book/appa.xml	(working copy)
@@ -25,7 +25,7 @@
     <title>Revision Numbers Are Different Now</title>
 
     <para>In CVS, revision numbers are per-file.  This is because CVS
-      uses RCS as a backend; each file has a corresponding RCS file in
+      previously used RCS as a backend; each file has a corresponding RCS file in
       the repository, and the repository is roughly laid out according
       to the structure of your project tree.</para>
 
Index: src/en/book/ch01.xml
===================================================================
--- src/en/book/ch01.xml	(revision 1533)
+++ src/en/book/ch01.xml	(working copy)
@@ -453,9 +453,11 @@
 
     <para>This command creates a new directory
       <filename>/path/to/repos</filename> which contains a Subversion
-      repository.  Make sure that this directory lives on a local
+      repository.  If you are creating a Berkeley DB repository (i.e.
+      using the <option>--fs-type=bdb</option> option with the
+      <command>svnadmin</command> command), make sure that this directory lives on a local
       disk, <emphasis>not</emphasis> a network share.  This new
-      directory mainly contains a collection of Berkeley DB database
+      directory mainly contains a collection of database
       files.  You won't see your versioned files if you peek inside.
       For more information about repository creation and maintenance,
       see <xref linkend="svn.reposadmin"/>.</para>
Index: src/en/book/ch02.xml
===================================================================
--- src/en/book/ch02.xml	(revision 1533)
+++ src/en/book/ch02.xml	(working copy)
@@ -54,7 +54,7 @@
       example, a client can ask historical questions like, <quote>What
       did this directory contain last Wednesday?</quote> or <quote>Who
       was the last person to change this file, and what changes did
-      they make?</quote> These are the sorts of questions that are at
+      he make?</quote> These are the sorts of questions that are at
       the heart of any <firstterm>version control system</firstterm>:
       systems that are designed to record and track changes to data
       over time.
@@ -530,8 +530,8 @@
           number selects an entire tree, a particular state of the
           repository after some committed change.  Another way to
           think about it is that revision N represents the state of
-          the repository filesystem after the Nth commit.  When a
-          Subversion user talks about <quote>revision 5 of
+          the repository filesystem after the Nth commit.  When
+          Subversion users talk about <quote>revision 5 of
           <filename>foo.c</filename></quote>, they really mean
           <quote><filename>foo.c</filename> as it appears in revision 5.</quote>
           Notice that in general, revisions N and M of a file do
Index: src/en/book/ch03.xml
===================================================================
--- src/en/book/ch03.xml	(revision 1533)
+++ src/en/book/ch03.xml	(working copy)
@@ -178,7 +178,7 @@
 
 $ svn diff --revision HEAD
 # compares your working file (with local mods) to the latest version
-# in the repository.
+# in the repository
 
 $ svn diff --revision BASE:HEAD foo.c
 # compares your <quote>pristine</quote> foo.c (no local mods) with the 
@@ -1713,7 +1713,7 @@
         <varlistentry>
           <term><command>svn log</command></term>
           <listitem>
-            <para>Shows you broad information: log messages attached
+            <para>Shows you broad information: log messages with date and author information attached
               to revisions, and which paths changed in each
               revision.</para>
           </listitem>
@@ -1751,10 +1751,10 @@
     <sect2 id="svn.tour.history.log">
       <title><command>svn log</command></title>
 
-      <para>To find information about the history of a file or
+      <para>To find information about the history of a file, symlink or
         directory, use the <command>svn log</command>
         command. <command>svn log</command> will provide you with a
-        record of who made changes to a file or directory, at what
+        record of who made changes to this file, symlink or directory, at what
         revision it changed, the time and date of that revision, and,
         if it was provided, the log message that accompanied the
         commit.</para>
Index: src/en/book/ch04.xml
===================================================================
--- src/en/book/ch04.xml	(revision 1533)
+++ src/en/book/ch04.xml	(working copy)
@@ -644,7 +644,7 @@
               tree-changes.</para>
           </footnote>
           The <command>svn merge</command> command, however, can express
-          tree-changes by directly applying them to your working
+          changes in tree structure and properties by directly applying them to your working
           copy.</para>
 
       </sidebar>
@@ -885,7 +885,7 @@
           Somebody can then run <command>svn log -r9238</command> to
           read about the exact changeset which fixed the bug, and run
           <command>svn diff -r9237:9238</command> to see the patch
-          itself.  And Subversion's merge command also uses revision
+          itself.  And Subversion's <command>merge</command> command also uses revision
           numbers.  You can merge specific changesets from one branch
           to another by naming them in the merge arguments:
           <command>svn merge -r9237:9238</command> would merge
@@ -1010,18 +1010,18 @@
           ancestry, while the latter command is quite sensitive to it.
           For example, if you asked <command>svn diff</command> to
           compare revisions 99 and 102 of <filename>foo.c</filename>,
-          you would see line-based diffs; the diff command is blindly
+          you would see line-based diffs; the <command>diff</command> command is blindly
           comparing two paths.  But if you asked <command>svn
           merge</command> to compare the same two objects, it would
           notice that they're unrelated and first attempt to delete
           the old file, then add the new file;  you would see a
-          <literal>D  foo.c</literal> followed by a <literal>A
-          foo.c</literal>.</para>
+          <literal>D  foo.c</literal> followed by a
+          <literal>A  foo.c</literal>.</para>
 
         <para>Most merges involve comparing trees that are ancestrally
           related to one another, and therefore <command>svn
           merge</command> defaults to this behavior.  Occasionally,
-          however, you may want the merge command to compare two
+          however, you may want the <command>merge</command> command to compare two
           unrelated trees.  For example, you may have imported two
           source-code trees representing different vendor releases of
           a software project (see <xref linkend="svn.advanced.vendorbr"/>).
@@ -1036,7 +1036,7 @@
           command, and it will behave just like <command>svn
           diff</command>.  (And conversely, the
           <option>--notice-ancestry</option> option will cause
-          <command>svn diff</command> to behave like the merge
+          <command>svn diff</command> to behave like the <command>merge</command>
           command.)</para>
 
       </sect3>
@@ -1319,7 +1319,7 @@
         directory, it may be gone from the <literal>HEAD</literal>
         revision, but the object still exists in earlier revisions.
         One of the most common questions new users ask is, <quote>How
-        do I get my old file or directory back?</quote></para>
+        do I get my old file or directory back?</quote>.</para>
 
       <para>The first step is to define exactly <emphasis
         role="bold">which</emphasis> item you're trying to resurrect.
@@ -1737,7 +1737,7 @@
       
       <para>Have you noticed that the output of <command>svn
         switch</command> and <command>svn update</command> look the
-        same?  The switch command is actually a superset of the
+        same?  The <command>switch</command> command is actually a superset of the
         update command.</para>
 
       <para>When you run <command>svn update</command>, you're asking
@@ -1745,7 +1745,7 @@
         and then sends a description of the differences back to the
         client. The only difference between <command>svn
         switch</command> and <command>svn update</command> is that the
-        update command always compares two identical paths.</para>
+        <command>update</command> command always compares two identical paths.</para>
       
       <para>That is, if your working copy is a mirror of
         <filename>/calc/trunk</filename>, then <command>svn
@@ -1910,7 +1910,7 @@
         changes made to your working copy, and you'd like a
         collaborator to see them.  Instead of running <command>svn
         diff</command> and sending a patch file (which won't capture
-        tree changes), you can instead use <command>svn copy</command>
+        tree changes, symlink changes or changes in properties), you can instead use <command>svn copy</command>
         to <quote>upload</quote> your working copy to a private area
         of the repository.  Your collaborator can then either checkout
         a verbatim copy of your working copy, or use <command>svn
@@ -1983,8 +1983,8 @@
         working copies.  If a user has a working copy of a particular
         repository directory, your <command>svn move</command>
         operation might remove the path from the latest revision.
-        When the user next runs <command>svn update</command>, they'll
-        be told that their working copy represents a path that no
+        When the user next runs <command>svn update</command>, she will
+        be told that her working copy represents a path that no
         longer exists, and the user will be forced to <command>svn
         switch</command> to the new location.
         </para>
@@ -2039,7 +2039,7 @@
         branch.  In software development, though, it's also common to
         have two <quote>main</quote> branches running side-by-side for
         very long periods.  For example, suppose it's time to release
-        a stable <filename>calc</filename> project to the public, and
+        a stable version of the <filename>calc</filename> project to the public, and
         you know it's going to take a couple of months to shake bugs
         out of the software.  You don't want people to add new
         features to the project, but you don't want to tell all
Index: src/en/book/ch05.xml
===================================================================
--- src/en/book/ch05.xml	(revision 1533)
+++ src/en/book/ch05.xml	(working copy)
@@ -1120,7 +1120,7 @@
           other queries, displaying subsets of bits of information
           we've mentioned previously, reporting which paths were
           modified in a given revision or transaction, showing textual
-          and property differences made to files and directories, and
+          and property differences made to files, symlinks and directories, and
           so on.  The following is a brief description of the current
           list of subcommands accepted by <command>svnlook</command>,
           and the output of those subcommands:</para>
@@ -1772,7 +1772,7 @@
 
       <para>Perhaps the most commonly used of
         <command>svnadmin</command>'s subcommands is
-        <literal>setlog</literal>.  When a transaction is committed to
+        <command>setlog</command>.  When a transaction is committed to
         the repository and promoted to a revision, the descriptive log
         message associated with that new revision (and provided by the
         user) is stored as an unversioned property attached to the
@@ -1788,7 +1788,7 @@
         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>svn</command> program's <command>propset</command>
         command (see <xref linkend="svn.ref"/>).  However, because of
         the potential to lose information forever, Subversion
         repositories are not, by default, configured to allow changes
@@ -1842,7 +1842,7 @@
         them.</para>
 
       <para>You can use <command>svnadmin</command>'s
-        <literal>lstxns</literal> command to list the names of the
+        <command>lstxns</command> command to list the names of the
         currently outstanding transactions.</para>
 
       <screen>
@@ -1862,7 +1862,7 @@
         removal!  If so, the transaction's 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>rmtxns</command> subcommand can take its input
         directly from the output of <literal>lstxns</literal>!</para>
 
       <screen>
@@ -2020,7 +2020,7 @@
           equal to the size of the original data, it only takes up
           enough space to say, <quote>I look just like this other
           piece of data over here, except for the following couple of
-          changes.</quote> Specifically, each time a new version of a
+          changes</quote>. Specifically, each time a new version of a
           file is committed to the repository, Subversion encodes the
           previous version (actually, several previous versions) as a
           delta against the new version.  The result is that most of
@@ -2237,7 +2237,7 @@
         requested range of revisions.  Note that <command>svnadmin
         dump</command> is reading revision trees from the repository
         just like any other <quote>reader</quote> process would
-        (<command>svn checkout</command>, for example.)  So it's safe
+        (<command>svn checkout</command>, for example).  So it's safe
         to run this command at any time.</para>
 
       <para>The other subcommand in the pair, <command>svnadmin
@@ -2451,7 +2451,7 @@
         <command>cvs2svn</command> utility (see <xref
         linkend="svn.forcvs.convert"/>) uses the dump format to represent the
         contents of a CVS repository so that those contents can be
-        moved in a Subversion repository.</para>
+        copied into a Subversion repository.</para>
 
     </sect2>
 
Index: src/en/book/ch06.xml
===================================================================
--- src/en/book/ch06.xml	(revision 1533)
+++ src/en/book/ch06.xml	(working copy)
@@ -5,7 +5,7 @@
     
     <para>A Subversion repository can be accessed simultaneously by
       clients running on the same machine on which the repository
-      resides using the <literal>file:///</literal> method.  But the
+      resides using the <literal>file://</literal> method.  But the
       typical Subversion setup involves a single server machine being
       accessed from clients on computers all over the office—or,
       perhaps, all over the world.</para>
@@ -398,7 +398,7 @@
       <para>If the client successfully authenticates by any of the
         methods listed above, it will attempt to cache the credentials
         on disk (unless the user has disabled this behavior, as
-        mentioned earlier.)</para>
+        mentioned earlier).</para>
 
     </sect2>
 
@@ -512,7 +512,7 @@
           repository directly needs to have proper read and write
           permissions on the entire repository.  If you're not
           careful, this can lead to a number of headaches, especially
-          if you're using a BerkeleyDB database rather than FSFS.  Be
+          if you're using a Berkeley DB database rather than FSFS.  Be
           sure to read <xref linkend="svn.serverconfig.multimethod"/>.</para>
 
         <para>Secondly, when configuring <command>svnserve</command>,
@@ -645,7 +645,7 @@
           client displays it in the authentication prompt, and uses it
           as a key (along with the server's hostname and port) for
           caching credentials on disk (see <xref
-          linkend="svn.serverconfig.netmodel.credcache"/>.)  The
+          linkend="svn.serverconfig.netmodel.credcache"/>).  The
           <literal>password-db</literal> variable points to a separate
           file that contains a list of usernames and passwords, using
           the same familiar format.  For example:</para>
@@ -823,7 +823,7 @@
       <para>You'd think that the story of SSH tunneling would end
         here, but it doesn't.  Subversion allows you to create custom
         tunnel behaviors in your run-time <filename>config</filename>
-        file (see <xref linkend="svn.advanced.confarea"/>.)  For example,
+        file (see <xref linkend="svn.advanced.confarea"/>).  For example,
         suppose you want to use RSH instead of SSH.  In the
         <literal>[tunnels]</literal> section of your
         <filename>config</filename> file, simply define it like
@@ -842,7 +842,7 @@
         scenes.  If you include a username in the URL (for example,
         <literal>svn+rsh://username@host/path</literal>) the client
         will also include that in its command (<command>rsh
-        username at host svnserve -t</command>.)  But you can define new
+        username at host svnserve -t</command>).  But you can define new
         tunneling schemes to be much more clever than that:</para>
 
 <screen>
@@ -1016,7 +1016,7 @@
       available to clients via the WebDAV/DeltaV protocol, which is an
       extension to HTTP 1.1
       (see <systemitem class="url">http://www.webdav.org/</systemitem>
-      for more information.) This protocol takes the ubiquitous HTTP
+      for more information). This protocol takes the ubiquitous HTTP
       protocol that is the core of the World Wide Web, and adds
       writing—specifically, versioned
       writing—capabilities.  The result is a standardized,
@@ -1497,7 +1497,7 @@
           will be cached in your private run-time
           <filename>auth/</filename> area in just the same way your
           username and password are cached (see <xref
-          linkend="svn.serverconfig.netmodel.credcache"/>.)  If cached, Subversion will
+          linkend="svn.serverconfig.netmodel.credcache"/>).  If cached, Subversion will
           automatically remember to trust this certificate in future
           negotiations.</para>
 
@@ -2248,7 +2248,7 @@
 </screen>
 
     <para>Another common problem is often encountered on Unix-like
-      systems.  As a repository is used, BerkeleyDB occasionally
+      systems.  As a repository is used, Berkeley DB occasionally
       creates new log files to journal its actions.  Even if the
       repository is wholly owned by the <command>svn</command> group,
       these newly created files won't necessarily be owned by that


More information about the svnbook-dev mailing list