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

sunny256 svnbook-dev at red-bean.com
Wed Aug 17 19:49:36 CDT 2005


Author: sunny256
Date: Wed Aug 17 19:49:35 2005
New Revision: 1619

Modified:
   trunk/src/en/book/appa.xml
   trunk/src/en/book/ch02.xml
   trunk/src/en/book/ch03.xml
   trunk/src/en/book/ch04.xml
   trunk/src/en/book/ch05.xml
   trunk/src/en/book/ch06.xml
Log:
Miscellaneous corrections to the book. Patch reviewed by cmpilato and 
maxb. Patch cleanup by maxb.

* src/en/book/appa.xml
  (svn.forcvs.revnums): Rephrase to avoid the misconception that CVS 
    still uses rcs(1) as a backend. (Wording by sussman.)

* src/en/book/ch02.xml
  (svn.basic.repository): Replace "they" with "he" when talking about a 
    user. Mixing he/she instead of using "they" is used other places in 
    the book.
  (svn.basic.in-action.revs): Use plural form of "user".

* src/en/book/ch03.xml
  (svn.tour.revs.keywords): Remove superfluous periods in screen 
    example.
  (svn.tour.history): Mention that "svn log" also lists author and date 
    information.

* src/en/book/ch04.xml
  (svn.branchmerge.copychanges.specific): Rephrase and also mention that 
    merging also affects properties.
  (svn.branchmerge.copychanges.bestprac.preview, 
   svn.branchmerge.copychanges.bestprac.ancestry): Add missing 
    <literal>s. Turn a status output from <literal> into <screen> to 
    retain whitespace.
  (svn.branchmerge.commonuses.resurrect): Add missing period.
  (svn.branchmerge.switchwc): Add missing <literal>s.
  (svn.branchmerge.tags.mkcomplex): Say that regular diffs don’t show 
    changes in symlinks and properties neither.
  (svn.branchmerge.maint.layout): Changed "they/their" to "she/her" when 
    talking about a user.
  (svn.branchmerge.maint.lifetime): Add three words to a sentence.

* src/en/book/ch05.xml
  (svn.reposadmin.maint.diskspace): Move period outside <quote>.
  (svn.reposadmin.maint.migrate): Move period outside parentheses. 
    Revisions are copied, not moved into the repository from a dump 
    file.

* src/en/book/ch06.xml
  (svn.serverconfig.netmodel.credcache, 
   svn.serverconfig.svnserve.auth.users, 
   svn.serverconfig.svnserve.sshauth, svn.serverconfig.httpd, 
   svn.serverconfig.httpd.authn.sslcerts): Move period outside 
    parentheses.
  (svn.serverconfig.svnserve.invoking.sb-1, 
   svn.serverconfig.multimethod): Insert space into "BerkeleyDB".


Modified: trunk/src/en/book/appa.xml
==============================================================================
--- trunk/src/en/book/appa.xml	(original)
+++ trunk/src/en/book/appa.xml	Wed Aug 17 19:49:35 2005
@@ -25,9 +25,9 @@
     <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
-      the repository, and the repository is roughly laid out according
-      to the structure of your project tree.</para>
+      stores its data in RCS files; 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>
 
     <para>In Subversion, the repository looks like a single
       filesystem.  Each commit results in an entirely new filesystem

Modified: trunk/src/en/book/ch02.xml
==============================================================================
--- trunk/src/en/book/ch02.xml	(original)
+++ trunk/src/en/book/ch02.xml	Wed Aug 17 19:49:35 2005
@@ -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.
@@ -531,14 +531,14 @@
           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
-          <emphasis>not</emphasis> necessarily differ!  Because CVS
-          uses per-file revisions numbers, CVS users might want to see
-          <xref linkend="svn.forcvs"/> for more details.</para>
+          <quote><filename>foo.c</filename> as it appears in revision
+            5.</quote> Notice that in general, revisions N and M of a
+          file do <emphasis>not</emphasis> necessarily differ!  Because
+          CVS uses per-file revisions numbers, CVS users might want to
+          see <xref linkend="svn.forcvs"/> for more details.</para>
       </sidebar>
 
       <para>It's important to note that working copies do not always

Modified: trunk/src/en/book/ch03.xml
==============================================================================
--- trunk/src/en/book/ch03.xml	(original)
+++ trunk/src/en/book/ch03.xml	Wed Aug 17 19:49:35 2005
@@ -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 
@@ -188,8 +188,8 @@
 # shows all commit logs since you last updated
 
 $ svn update --revision PREV foo.c
-# rewinds the last change on foo.c.
-# (foo.c's working revision is decreased.)
+# rewinds the last change on foo.c
+# (foo.c's working revision is decreased)
 </screen>
       
       <para>These keywords allow you to perform many common (and
@@ -1713,9 +1713,9 @@
         <varlistentry>
           <term><command>svn log</command></term>
           <listitem>
-            <para>Shows you broad information: log messages attached
-              to revisions, and which paths changed in each
-              revision.</para>
+            <para>Shows you broad information: log messages with date
+              and author information attached to revisions, and which
+              paths changed in each revision.</para>
           </listitem>
         </varlistentry>
 

Modified: trunk/src/en/book/ch04.xml
==============================================================================
--- trunk/src/en/book/ch04.xml	(original)
+++ trunk/src/en/book/ch04.xml	Wed Aug 17 19:49:35 2005
@@ -641,11 +641,11 @@
           <footnote>
             <para>In the future, the Subversion project plans to use
               (or invent) an expanded patch format that describes
-              tree-changes.</para>
+              changes in tree structure and properties.</para>
           </footnote>
           The <command>svn merge</command> command, however, can express
-          tree-changes by directly applying them to your working
-          copy.</para>
+          changes in tree structure and properties by directly applying
+          them to your working copy.</para>
 
       </sidebar>
       
@@ -885,11 +885,11 @@
           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
-          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
-          changeset #9238 into your working copy.</para>
+          itself.  And Subversion's <literal>merge</literal> 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 changeset #9238 into your working copy.</para>
       </sidebar>
 
       <sect3 id="svn.branchmerge.copychanges.bestprac.merge">
@@ -1010,21 +1010,26 @@
           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
-          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>
+          you would see line-based diffs; the <literal>diff</literal>
+          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;  the output would
+          indicate a deletion followed by an add:</para>
+
+        <screen>
+D  foo.c
+A  foo.c
+</screen>
 
         <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
-          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"/>).
+          however, you may want the <literal>merge</literal> 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"/>).
           If you asked <command>svn merge</command> to compare the two
           trees, you'd see the entire first tree being deleted,
           followed by an add of the entire second tree!</para>
@@ -1036,8 +1041,8 @@
           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.)</para>
+          <command>svn diff</command> to behave like the
+          <literal>merge</literal> command.)</para>
 
       </sect3>
 
@@ -1319,7 +1324,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,15 +1742,16 @@
       
       <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
-        update command.</para>
+        same?  The <literal>switch</literal> command is actually a
+        superset of the update command.</para>
 
       <para>When you run <command>svn update</command>, you're asking
         the repository to compare two trees.  The repository does so,
         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>
+        <literal>update</literal> 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,11 +1916,12 @@
         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>
-        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
-        merge</command> to receive your exact changes.</para>
+        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 merge</command> to receive
+        your exact changes.</para>
 
     </sect2>
 
@@ -1983,8 +1990,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,10 +2046,10 @@
         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
-        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
+        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
         developers to stop programming either.  So instead, you create
         a <quote>stable</quote> branch of the software that won't
         change much:</para>

Modified: trunk/src/en/book/ch05.xml
==============================================================================
--- trunk/src/en/book/ch05.xml	(original)
+++ trunk/src/en/book/ch05.xml	Wed Aug 17 19:49:35 2005
@@ -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>
 

Modified: trunk/src/en/book/ch06.xml
==============================================================================
--- trunk/src/en/book/ch06.xml	(original)
+++ trunk/src/en/book/ch06.xml	Wed Aug 17 19:49:35 2005
@@ -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,9 +1497,9 @@
           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
-          automatically remember to trust this certificate in future
-          negotiations.</para>
+          linkend="svn.serverconfig.netmodel.credcache"/>).  If cached,
+          Subversion will automatically remember to trust this certificate
+          in future negotiations.</para>
 
         <para>Your run-time <filename>servers</filename> file also gives
           you the ability to make your Subversion client automatically
@@ -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