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

sussman noreply at red-bean.com
Sun Mar 2 23:46:36 CST 2008


Author: sussman
Date: Sun Mar  2 23:46:35 2008
New Revision: 2986

Log:
* ch04-branching-and-merging.xml:  enter O'Reilly's copyedits.

Modified:
   trunk/src/en/book/ch04-branching-and-merging.xml

Modified: trunk/src/en/book/ch04-branching-and-merging.xml
==============================================================================
--- trunk/src/en/book/ch04-branching-and-merging.xml	(original)
+++ trunk/src/en/book/ch04-branching-and-merging.xml	Sun Mar  2 23:46:35 2008
@@ -12,7 +12,7 @@
     almost all version control systems.  If you're not familiar with
     these ideas, we provide a good introduction in this chapter.  If
     you are familiar, then hopefully you'll find it interesting to
-    see how Subversion implements these ideas.</para>
+    see how Subversion implements them.</para>
 
   <para>Branching is a fundamental part of version control.  If
     you're going to allow Subversion to manage your data, then this
@@ -28,21 +28,20 @@
     <title>What's a Branch?</title>
 
     <para>Suppose it's your job to maintain a document for a division
-      in your company, a handbook of some sort.  One day a different
+      in your company—a handbook of some sort.  One day a different
       division asks you for the same handbook, but with a few parts
       <quote>tweaked</quote> for them, since they do things slightly
       differently.</para>
 
-    <para>What do you do in this situation?  You do the obvious thing:
-      you make a second copy of your document, and begin maintaining
-      the two copies separately.  As each department asks you to make
-      small changes, you incorporate them into one copy or the
-      other.</para>
+    <para>What do you do in this situation?  You do the obvious: make
+      a second copy of your document and begin maintaining the two
+      copies separately.  As each department asks you to make small
+      changes, you incorporate them into one copy or the other.</para>
 
     <para>You often want to make the same change to both copies.  For
       example, if you discover a typo in the first copy, it's very
       likely that the same typo exists in the second copy.  The two
-      documents are almost the same, after all; they only differ in
+      documents are almost the same, after all; they differ only in
       small, specific ways.</para>
 
     <para>This is the basic concept of a
@@ -112,7 +111,7 @@
       the fact that the latest version of the project (in
       <filename>/calc/trunk</filename>) is always usable.  If you
       start committing your changes bit-by-bit, you'll surely break
-      things for Sally (and other team members as well.)</para>
+      things for Sally (and other team members as well).</para>
 
     <para>One strategy is to crawl into a hole: you and Sally can stop
       sharing information for a week or two.  That is, start gutting
@@ -125,12 +124,12 @@
       do your work on different computers (perhaps you have a working
       copy of <filename>/calc/trunk</filename> on two different
       machines), you'll need to manually copy your changes back and
-      forth, or just do all the work on a single computer.  By that
+      forth or just do all the work on a single computer.  By that
       same token, it's difficult to share your changes-in-progress
       with anyone else.  A common software development <quote>best
       practice</quote> is to allow your peers to review your work as
       you go.  If nobody sees your intermediate commits, you lose
-      potential feedback, and may end up going down the wrong path for
+      potential feedback and may end up going down the wrong path for
       weeks before another person on your team notices.  Finally, when
       you're finished with all your changes, you might find it very
       difficult to re-merge your final work with the rest of the
@@ -197,7 +196,7 @@
         using <command>svn copy</command> to duplicate a directory
         within the working copy, this technique isn't recommended.  It
         can be quite slow, in fact!  Copying a directory on the
-        client-side is a linear-time operation, in that it actually
+        client side is a linear-time operation, in that it actually
         has to duplicate every file and subdirectory on local disk.
         Copying a directory on the server, however, is a constant-time
         operation, and it's the way most people create
@@ -220,17 +219,17 @@
           the same concept behind a hard-link.  As further changes are
           made to files and directories beneath the copied directory,
           Subversion continues to employ this hard-link concept where
-          it can.  It only duplicates data when it is necessary to
+          it can.  It duplicates data only when it is necessary to
           disambiguate different versions of objects.</para>
 
         <para>This is why you'll often hear Subversion users talk
-          about <quote>cheap copies</quote>.  It doesn't matter how
+          about <quote>cheap copies.</quote>  It doesn't matter how
           large the directory is—it takes a very tiny, constant
           amount of time and space to make a copy of it.  In fact,
           this feature is the basis of how commits work in Subversion:
           each revision is a <quote>cheap copy</quote> of the previous
           revision, with a few items lazily changed within.  (To read
-          more about this, visit Subversion's website and read about
+          more about this, visit Subversion's web site and read about
           the <quote>bubble up</quote> method in Subversion's design
           documents.)</para>
 
@@ -292,8 +291,8 @@
         </listitem>
       </itemizedlist>
 
-      <para>There are now two independent lines of development, shown
-        in <xref linkend="svn.branchmerge.using.work.dia-1"/>, happening on
+      <para>There are now two independent lines of development (shown
+        in <xref linkend="svn.branchmerge.using.work.dia-1"/>) happening on
         <filename>integer.c</filename>.</para>
 
       <figure id="svn.branchmerge.using.work.dia-1">
@@ -384,9 +383,10 @@
         these two commits affected different files in different
         repository locations.  However, Subversion
         <emphasis>does</emphasis> show that the two files share a
-        common history.  Before the branch-copy was made in revision
-        341, they used to be the same file.  That's why you and Sally
-        both see the changes made in revisions 303 and 98.</para>
+        common history.  Before the branch copy was made in revision
+        341, the files used to be the same file.  That's why you and
+        Sally both see the changes made in revisions 303 and
+        98.</para>
 
     </sect2>
 
@@ -396,7 +396,7 @@
 
       <para>There are two important lessons that you should remember
         from this section.  First, Subversion has no internal concept
-        of a branch—it only knows how to make copies.  When you
+        of a branch—it knows only how to make copies.  When you
         copy a directory, the resulting directory is only
         a <quote>branch</quote> because <emphasis>you</emphasis>
         attach that meaning to it.  You may think of the directory
@@ -454,7 +454,7 @@
       changes can be copied back into the trunk.  In Subversion
       terminology, the general act of replicating changes from one
       branch to another is called <firstterm>merging</firstterm>, and
-      is performed using various invocations of the <command>svn
+      it is performed using various invocations of the <command>svn
       merge</command> command.</para>
 
     <para>In the examples that follow, we're assuming that both your
@@ -464,12 +464,12 @@
       automatically, and you'll have to use painful manual methods to
       achieve similar results.  That is, you'll always need to use the
       detailed merge syntax to specify specific ranges of revisions to
-      replicate (See <xref
-      linkend="svn.branchmerge.advanced.advancedsyntax"/>), and take
-      special care to keep track of what's already been merged and
-      what hasn't.  For this reason, we <emphasis>strongly</emphasis>
-      recommend making sure that your client and server are at least
-      version 1.5 or later.</para>
+      replicate (See
+      <xref linkend="svn.branchmerge.advanced.advancedsyntax"/> later
+      in this chapter), and take special care to keep track of what's
+      already been merged and what hasn't.  For this reason,
+      we <emphasis>strongly</emphasis> recommend making sure that your
+      client and server are at least version 1.5 or later.</para>
 
   <!-- =============================================================== -->
     <sect2 id="svn.branchmerge.changesets">
@@ -484,14 +484,13 @@
         a <firstterm>changeset</firstterm>.</para>
 
       <para>Everyone seems to have a slightly different definition
-        of <quote>changeset</quote>, or at least a different
+        of <quote>changeset,</quote> or at least a different
         expectation of what it means for a version control system to
-        have them.  For our purpose, let's say that a changeset is
-        just a collection of changes with a unique name.  The changes
-        might include textual edits to file contents, modifications to
-        tree structure, or tweaks to metadata.  In more common speak,
-        a changeset is just a patch with a name you can refer
-        to.</para>
+        have one.  For our purpose, let's say that a changeset is just
+        a collection of changes with a unique name.  The changes might
+        include textual edits to file contents, modifications to tree
+        structure, or tweaks to metadata.  In more common speak, a
+        changeset is just a patch with a name you can refer to.</para>
 
       <para>In Subversion, a global revision number N names a tree in
         the repository: it's the way the repository looked after the
@@ -502,9 +501,9 @@
         you use an issue tracker to manage bugs, you can use the
         revision numbers to refer to particular patches that fix
         bugs—for example,
-        <quote>this issue was fixed by revision 9238.</quote>.
-        Somebody can then run <command>svn log -r 9238</command> to
-        read about the exact changeset which fixed the bug, and run
+        <quote>this issue was fixed by revision 9238.</quote> Somebody
+        can then run <command>svn log -r 9238</command> to read about
+        the exact changeset that fixed the bug, and run
         <command>svn diff -c 9238</command> to see the patch itself.
         And (as you'll see shortly)
         Subversion's <command>merge</command> command is able to use
@@ -532,12 +531,13 @@
         prevent <quote>surprise</quote> conflicts when it comes time
         for you to fold your changes back into the trunk.</para>
 
-      <para>Subversion is aware of the history of your branch, and
+      <para>Subversion is aware of the history of your branch and
         knows when it divided away from the trunk.  To replicate the
         latest, greatest trunk changes to your branch, first make sure
         your working copy of the branch
         is <quote>clean</quote>—that it has no local
-        modifications.  Then simply run:</para>
+        modifications reported by <command>svn status</command>.  Then
+        simply run:</para>
 
       <screen>
 $ pwd
@@ -561,9 +561,9 @@
 </screen>
 
       <para>At this point, the wise thing to do is look at the changes
-        carefully with <command>svn diff</command>, then build and
+        carefully with <command>svn diff</command>, and then build and
         test your branch.  You might need to resolve some conflicts
-        (just as you do with <command>svn update</command>), or
+        (just as you do with <command>svn update</command>) or
         possibly make some small edits to get things working properly.
         (Remember, just because there are
         no <emphasis>syntactic</emphasis> conflicts doesn't mean there
@@ -575,7 +575,7 @@
         submit your changes into the repository:</para>
 
       <screen>
-$ svn commit -m "Merged /trunk to /my-calc-branch."
+$ svn commit -m "Merged latest trunk changes to my-calc-branch."
 Sending        button.c
 Sending        integer.c
 Transmitting file data ..
@@ -613,15 +613,15 @@
           difference.  But <command>svn merge</command> has special
           abilities that surpass the <command>patch</command> program.
           The file format used by <command>patch</command> is quite
-          limited; it's only able to tweak file contents.  There's no
+          limited; it's able to tweak file contents only.  There's no
           way to represent changes to <emphasis>trees</emphasis>, such
           as the addition, removal, or renaming of files and
           directories.  Nor can the <command>patch</command> program
           notice changes to properties.  If Sally's change had,
           say, added a new directory, the output of <command>svn
           diff</command> wouldn't have mentioned it at
-          all.  <command>svn diff</command> only outputs the limited
-          patch-format, so there are some ideas it simply can't
+          all.  <command>svn diff</command> outputs only the limited
+          patch format, so there are some ideas it simply can't
           express.</para>
 
         <para>The <command>svn merge</command> command, however, can
@@ -654,7 +654,7 @@
 </screen>
 
       <para>Subversion knows which trunk changes you've already
-        replicated to your branch, so it carefully only replicates
+        replicated to your branch, so it carefully replicates only
         those changes you don't yet have.  Once again, you'll have to
         build, test, and <command>svn commit</command> the local
         modifications to your branch.</para>
@@ -662,8 +662,8 @@
       <para>What happens when you finally finish your work, though?
         Your new feature is done, and you're ready to merge your
         branch changes back to the trunk (so your team can enjoy the
-        bounty of your labor.)  The process is simple.  First, bring
-        your branch in sync with trunk again, just as you've been
+        bounty of your labor).  The process is simple.  First, bring
+        your branch in sync with the trunk again, just as you've been
         doing all along:</para>
 
       <screen>
@@ -682,22 +682,22 @@
 </screen>
 
       <para>Now, you use <command>svn merge</command> to replicate
-        your branch changes back into the trunk.  To do this, you'll
-        need an up-to-date working copy
-        of <filename>/trunk</filename>.  You can do this by either
-        doing an <command>svn checkout</command>, dredging up an old
-        trunk working copy from somewhere on your disk, or by
-        using <command>svn switch</command> (see
+        your branch changes back into the trunk.  You'll need an
+        up-to-date working copy of <filename>/trunk</filename>.  You
+        can do this by either doing an <command>svn
+        checkout</command>, dredging up an old trunk working copy from
+        somewhere on your disk, or by using <command>svn
+        switch</command> (see
         <xref linkend="svn.branchmerge.switchwc"/>.) However you get a
         trunk working copy, remember that it's a best practice to do
         your merge into a working copy that
         has <emphasis>no</emphasis> local edits and has been recently
         updated.  If your working copy isn't <quote>clean</quote> in
-        these ways, you can run into some conflict-related
+        these ways, you can run into some unnecessary conflict-related
         headaches.</para>
 
-      <para>Once you have a clean working copy of trunk,
-        you're ready merge your branch back into it:</para>
+      <para>Once you have a clean working copy of the trunk, you're
+        ready merge your branch back into it:</para>
 
       <screen>
 $ pwd
@@ -726,8 +726,8 @@
         back</quote> is a different sort of work than what you've been
         doing up until now.  Previously, we had been
         asking <command>svn merge</command> to grab the <quote>next
-        set</quote> of changes one branch and duplicate them to
-        another branch.  This is fairly straightforward, and each time
+        set</quote> of changes from one branch and duplicate them to
+        another.  This is fairly straightforward, and each time
         Subversion knows how to pick up where it left off.  In our
         prior examples, you can see that first it merges the ranges
         345:356 from trunk to branch; later on, it continues by
@@ -747,7 +747,8 @@
         changes!)</para>
 
       <para>Now that your branch is merged to trunk, you'll no longer
-        need your branch.  You can do some basic housecleaning in the
+        need your branch.  You can destroy your working copy of the
+        branch, and also do some basic housecleaning in the
         repository:</para>
 
       <screen>
@@ -757,15 +758,15 @@
 
       <para>But wait!  Isn't the history of that branch valuable?
         What if somebody wants to audit the evolution of your feature
-        someday, and look at all your commits?  No need to worry.
-        Remember that even though your branch is no longer visible in
-        the <filename>/branches</filename> directory, its existence is
-        still an immutable part of the repository's history.  A
-        simple <command>svn log</command> command on
+        someday and look at all of your branch changes?  No need to
+        worry.  Remember that even though your branch is no longer
+        visible in the <filename>/branches</filename> directory, its
+        existence is still an immutable part of the repository's
+        history.  A simple <command>svn log</command> command on
         the <filename>/branches</filename> URL will show the entire
         history of your branch.  Your branch can even be resurrected
-        at some point, should you desire.  (See
-        <xref linkend="svn.branchmerge.advanced.resurrect"/>.)</para>
+        at some point, should you desire (see
+        <xref linkend="svn.branchmerge.advanced.resurrect"/>).</para>
 
     </sect2>
 
@@ -818,12 +819,12 @@
 
       <para>The <command>svn mergeinfo</command> command, by default,
         looks back at the history of the thing you're querying and
-        tries to make a sane guess about the <quote>source</quote> you
-        want to be copying changes from.  In our prior example,
-        because we're querying our branch working copy, the command
-        assumes we're interested in receiving changes
+        tries to make a sane guess about the <quote>source</quote>
+        from which you want to be copying changes.  In our prior
+        example, because we're querying our branch working copy, the
+        command assumes we're interested in receiving changes
         from <filename>/trunk</filename> (since that's where our
-        branch was originally copied from.)  However, if another
+        branch was originally copied from).  However, if another
         coworker had a different branch going on that we wanted to
         merge changes from, we could have this command tell us about
         eligible changesets from that source too:</para>
@@ -851,13 +852,24 @@
 </screen>
 
       <para>The <option>--dry-run</option> option doesn't actually
-        apply any local changes to the working copy.  It only shows
+        apply any local changes to the working copy.  It shows only
         status codes that <emphasis>would</emphasis> be printed in a
         real merge.  It's useful for getting a <quote>high
         level</quote> preview of the potential merge, for those times
         when running <command>svn diff</command> gives too much
         detail.</para>
 
+      <tip>
+        <para>After performing a merge operation, but before committing
+          the results of the merge, you can use <command>svn diff
+          --depth=empty /path/to/merge/target</command> to see only
+          the changes to the immediate target of your merge.  If your
+          merge target was a directory, only property differences will
+          be displayed.  This is a handy way to see the changes to the
+          svn:mergeinfo property recorded by the merge operation,
+          which will remind you about what you've just merged.</para>
+      </tip>
+
       <para>Of course, the best way to preview a merge operation is to
         just do it!  Remember, running <command>svn merge</command>
         isn't an inherently risky thing; if you don't like the
@@ -871,29 +883,18 @@
           running <command>svn merge</command> and <command>svn
           revert</command> over and over, you may run into some
           annoying (but easily bypassed) roadblocks.  For example, if
-          the merge operation adds a new file (i.e. schedules it for
+          the merge operation adds a new file (i.e., schedules it for
           addition), then <command>svn revert</command> won't actually
           remove the file; it simply unschedules the addition.  You're
           left with an unversioned file.  If you then attempt to run
           the merge again, you may get conflicts due to the
-          unversioned file <quote>being in the way</quote>.  Solution?
+          unversioned file <quote>being in the way.</quote> Solution?
           After performing a revert, be sure to clean up the working
           copy and remove unversioned files and directories.  The
           output of <command>svn status</command> should be as clean
           (read: empty) as possible!</para>
       </tip>
 
-      <tip>
-        <para>After performing a merge operation, but before committing
-          the results of the merge, you can use <command>svn diff
-          --depth=empty /path/to/merge/target</command> to see only
-          the changes to the immediate target of your merge.  If your
-          merge target was a directory, only property diffs will be
-          displayed.  This is a handy way to see the changes to the
-          svn:mergeinfo property recorded by the merge operation,
-          which will remind you about what you've just merged.</para>
-      </tip>
-
     </sect2>
 
   </sect1>
@@ -907,11 +908,11 @@
     <para>Here ends the automated magic.  Sooner or later, once you
       get the hang of branching and merging, you're going to have to
       ask Subversion to merge <emphasis>specific</emphasis> changes
-      from one place to another.  And in order to do this, you're
-      going to have to start passing more complicated arguments
-      to <command>svn merge</command>.  This next section describes
-      the fully-expanded syntax of the merge command, and discusses a
-      number of common scenarios that require it.</para>
+      from one place to another.  In order to do this, you're going to
+      have to start passing more complicated arguments to <command>svn
+      merge</command>.  This next section describes the fully expanded
+      syntax of the command and discusses a number of common
+      scenarios that require it.</para>
 
 
     <!-- =============================================================== -->
@@ -934,7 +935,7 @@
         It comes up more often than you'd think.  For example, let's
         go back in time and imagine that you haven't yet merged your
         private feature-branch back to the trunk.  At the
-        water-cooler, you get word that Sally made an interesting
+        water cooler, you get word that Sally made an interesting
         change to <filename>integer.c</filename> on the trunk.
         Looking over the history of commits to the trunk, you see that
         in revision 355 she fixed a critical bug that directly
@@ -1017,7 +1018,7 @@
         independent patches to your working copy in order to skip over
         changeset 355, which your branch already contained.  There's
         nothing inherently wrong with this, except that it has the
-        potential to make conflict-resolution more tricky.  If the
+        potential to make conflict resolution more tricky.  If the
         first range of changes creates conflicts,
         you <emphasis>must</emphasis> resolve them interactively in
         order for the merge process to continue and apply the second
@@ -1034,28 +1035,29 @@
         do have different syntax in many cases.  Be sure to read about
         them in <xref linkend="svn.ref"/> for details, or ask
         <command>svn help</command>.  For example, <command>svn
-        merge</command> requires a working-copy path as a target, i.e.
+        merge</command> requires a working-copy path as a target, i.e.,
         a place where it should apply the generated patch.  If the
         target isn't specified, it assumes you are trying to perform
         one of the following common operations:</para>
 
-      <orderedlist>
+      <itemizedlist>
         <listitem>
           <para>You want to merge directory changes into your current
             working directory.</para>
         </listitem>
         <listitem>
           <para>You want to merge the changes in a specific file into
-            a file by the same name which exists in your current working
+            a file by the same name that exists in your current working
             directory.</para>
         </listitem>
-      </orderedlist>
+      </itemizedlist>
 
       <para>If you are merging a directory and haven't specified a
-        target path, <command>svn merge</command> assumes the first case
-        above and tries to apply the changes into your current
-        directory.  If you are merging a file, and that file (or a file
-        by the same name) exists in your current working directory,
+        target path, <command>svn merge</command> assumes the first
+        case and tries to apply the changes into your current
+        directory.  If you are merging a file, and that file (or a
+        file by the same name) exists in your current working
+        directory,
         <command>svn merge</command> assumes the second case and tries
         to apply the changes to a local file with the same name.</para>
 
@@ -1070,7 +1072,7 @@
         If you're feeling confused about exactly how merging works,
         you're not alone.  Many users (especially those new to version
         control) are initially perplexed about the proper syntax of
-        the command, and about how and when the feature should be
+        the command and about how and when the feature should be
         used.  But fear not, this command is actually much simpler
         than you think!  There's a very easy technique for
         understanding exactly how <command>svn merge</command>
@@ -1088,13 +1090,14 @@
 
       <para>If you're using <command>svn merge</command> to do basic
         copying of changes between branches, it will generally do the
-        right thing automatically.  For example, a command like</para>
+        right thing automatically.  For example, a command like the
+        following:</para>
 
       <screen>
 $ svn merge http://svn.example.com/repos/calc/some-branch
 </screen>
 
-      <para>... will attempt to duplicate any changes made
+      <para>will attempt to duplicate any changes made
         on <filename>some-branch</filename> into your current working
         directory, which is presumably a working copy that shares some
         historical connection to the branch.  The command is smart
@@ -1112,15 +1115,15 @@
 
         <listitem><para>An initial repository tree (often called the
         <firstterm>left side</firstterm> of the
-        comparison),</para></listitem>
+        comparison)</para></listitem>
 
         <listitem><para>A final repository tree (often called the
         <firstterm>right side</firstterm> of the
-        comparison),</para></listitem>
+        comparison)</para></listitem>
 
         <listitem><para>A working copy to accept the differences as
         local changes (often called the <firstterm>target</firstterm>
-        of the merge).</para></listitem>
+        of the merge)</para></listitem>
 
       </orderedlist>
 
@@ -1128,7 +1131,7 @@
         are compared, and the resulting differences are applied to the
         target working copy as local modifications.  When the command
         is done, the results are no different than if you had
-        hand-edited the files, or run various <command>svn
+        hand-edited the files or run various <command>svn
         add</command> or <command>svn delete</command> commands
         yourself.  If you like the results, you can commit them.  If
         you don't like the results, you can simply <command>svn
@@ -1199,7 +1202,7 @@
       <para>As we mentioned earlier, one way to think about a
         repository revision is as a specific changeset.  By using the
         <option>-r</option> option, you can ask <command>svn
-        merge</command> to apply a changeset, or whole range of
+        merge</command> to apply a changeset, or a whole range of
         changesets, to your working copy.  In our case of undoing a
         change, we're asking <command>svn merge</command> to apply
         changeset #303 to our working copy
@@ -1231,7 +1234,7 @@
         (Perhaps somebody accidentally committed a confidential
         document.)  This isn't so easy, it turns out, because
         Subversion was deliberately designed to never lose
-        information.  Revisions are immutable trees which build upon
+        information.  Revisions are immutable trees that build upon
         one another.  Removing a revision from history would cause a
         domino effect, creating chaos in all subsequent revisions and
         possibly invalidating all working copies.
@@ -1255,7 +1258,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
@@ -1272,13 +1275,13 @@
       <para>First, you might need to use <command>svn log</command> to
         discover the exact coordinate pair you wish to resurrect.  A
         good strategy is to run <command>svn log
-        --verbose</command> in a directory which used to contain your
-        deleted item.  The <option>--verbose (-v)</option> option shows a
-        list of all changed items in each revision; all you need to do
-        is find the revision in which you deleted the file or
-        directory.  You can do this visually, or by using another tool
-        to examine the log output (via <command>grep</command>, or
-        perhaps via an incremental search in an editor).</para>
+        --verbose</command> in a directory that used to contain your
+        deleted item.  The <option>--verbose (-v)</option> option
+        shows a list of all changed items in each revision; all you
+        need to do is find the revision in which you deleted the file
+        or directory.  You can do this visually, or by using another
+        tool to examine the log output (via <command>grep</command>,
+        or perhaps via an incremental search in an editor).</para>
 
       <screen>
 $ cd parent-dir
@@ -1309,12 +1312,12 @@
         choices.</para>
 
       <para>One option is to use <command>svn merge</command> to apply
-        revision 808 <quote>in reverse</quote>.  (We've already
-        discussed how to undo changes, see
-        <xref linkend="svn.branchmerge.advanced.undo"/>.)  This
-        would have the effect of re-adding <filename>real.c</filename>
-        as a local modification.  The file would be scheduled for
-        addition, and after a commit, the file would again exist
+        revision 808 <quote>in reverse.</quote> (We've already
+        discussed how to undo changes in
+        <xref linkend="svn.branchmerge.advanced.undo"/>.)  This would
+        have the effect of re-adding <filename>real.c</filename> as a
+        local modification.  The file would be scheduled for addition,
+        and after a commit, the file would again exist
         in <literal>HEAD</literal>.</para>
 
       <para>In this particular example, however, this is probably not
@@ -1348,7 +1351,7 @@
 
       <para>The plus sign in the status output indicates that the item
         isn't merely scheduled for addition, but scheduled for
-        addition <quote>with history</quote>.  Subversion remembers
+        addition <quote>with history.</quote>  Subversion remembers
         where it was copied from.  In the future, running <command>svn
         log</command> on this file will traverse back through the
         file's resurrection and through all the history it had prior
@@ -1422,8 +1425,9 @@
         to apply as much of the delta as possible, but some parts may
         be impossible.  Just as the Unix
         <command>patch</command> command sometimes complains about
-        <quote>failed hunks</quote>, <command>svn merge</command>
-        will complain about <quote>skipped targets</quote>:</para>
+        <quote>failed hunks,</quote> <command>svn merge</command> will
+        similarly complain about <quote>skipped
+        targets</quote>:</para>
 
       <screen>
 $ svn merge -r 1288:1351 http://svn.example.com/repos/branch
@@ -1447,7 +1451,7 @@
         recursively revert all the changes created by the merge
         (<command>svn revert --recursive</command>), delete any
         unversioned files or directories left behind after the
-        revert, and re-run <command>svn merge</command> with
+        revert, and rerun <command>svn merge</command> with
         different arguments.</para>
 
       <para>Also notice that the previous example shows a conflict
@@ -1484,26 +1488,26 @@
     <sect2 id="svn.branchmerge.advanced.blockchanges">
       <title>Blocking Changes</title>
 
-      <para>Sometimes there's a particular changeset which you don't
+      <para>Sometimes there's a particular changeset that you don't
         want to be automatically merged.  For example, perhaps your
         team's policy is to do new development work on
         <filename>/trunk</filename>, but to be more conservative about
-        backporting changes to a <quote>stable</quote> branch you use
-        for releasing to the public.  On one extreme, you can manually
-        cherrypick single changesets from trunk to the
-        branch—only the changes that are stable enough to pass
-        muster.  Maybe things aren't quite that strict, though;
-        perhaps most of the time you'd like to just let <command>svn
-        merge</command> automatically merge most changes from trunk to
-        branch.  In this case, you'd like a way to mask a few specific
-        changes out, i.e. prevent them from ever being automatically
+        backporting changes to a stable branch you use for releasing
+        to the public.  On one extreme, you can manually cherrypick
+        single changesets from trunk to the branch—just the
+        changes that are stable enough to pass muster.  Maybe things
+        aren't quite that strict, though; perhaps most of the time
+        you'd like to just let <command>svn merge</command>
+        automatically merge most changes from trunk to branch.  In
+        this case, you'd like a way to mask a few specific changes
+        out, i.e. prevent them from ever being automatically
         merged.</para>
 
       <para>In Subversion 1.5, the only way to block a changeset is to
         make the system believe that the change has
         <emphasis>already</emphasis> been merged.  You'll need to
         manually edit the <literal>svn:mergeinfo</literal> property on
-        the branch, and add the blocked revision(s) to the
+        the branch and add the blocked revision(s) to the
         list:</para>
 
       <screen>
@@ -1517,20 +1521,20 @@
 </screen>
 
       <para>This technique works, but it's also a little bit
-        dangerous.  The main problem is that we're not differentiating
-        between the ideas of <quote>I don't want this change</quote>
-        and <quote>I don't have this change</quote>.  We're
-        effectively lying to the system, making it think that the
-        change was previously merged.  This puts the responsibility on
-        you—the user—to remember that the change wasn't
-        actually merged, it just wasn't wanted.  There's no way to ask
-        Subversion for a list of <quote>blocked changelists</quote>.
-        If you want to track them (so that you can unblock them
-        someday) you'll need to record it in a text file somewhere, or
-        perhaps in an invented property.  In Subversion 1.5,
-        unfortunately, this is the only way to manage blocked
-        revisions; the plans are to make a better interface for this
-        in future versions.</para>
+        dangerous.  The main problem is that we're not clearly
+        differentiating between the ideas of <quote>I don't want this
+        change</quote> and <quote>I don't have this change.</quote>
+        We're effectively lying to the system, making it think that
+        the change was previously merged.  This puts the
+        responsibility on you—the user—to remember that
+        the change wasn't actually merged, it just wasn't wanted.
+        There's no way to ask Subversion for a list of <quote>blocked
+        changelists.</quote> If you want to track them (so that you
+        can unblock them someday.) you'll need to record them in a
+        text file somewhere, or perhaps in an invented property.  In
+        Subversion 1.5, unfortunately, this is the only way to manage
+        blocked revisions; the plans are to make a better interface
+        for this in future versions.</para>
 
     </sect2>
 
@@ -1688,7 +1692,7 @@
         <filename>foo.c at 102</filename> may appear to be related
         (they have the same path), but in fact are completely
         different objects in the repository.  They share no history
-        or <quote>ancestry</quote>.</para>
+        or <quote>ancestry.</quote></para>
 
       <para>The reason for bringing this up is to point out an
         important difference between <command>svn diff</command> and
@@ -1696,7 +1700,7 @@
         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 <literal>diff</literal>
+        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
@@ -1709,24 +1713,24 @@
       </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 <literal>merge</literal> command
-        to compare two unrelated trees.  For example, you may have
+        related to one another; therefore, <command>svn
+        merge</command> defaults to this behavior.  Occasionally,
+        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"/>).  If you asked
+        releases of a software project (see
+        <xref linkend="svn.advanced.vendorbr"/>).  If you ask
         <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!  In these situations, you'll want
         <command>svn merge</command> to do a path-based comparison
         only, ignoring any relations between files and directories.
         Add the <option>--ignore-ancestry</option> option to your
-        merge command, and it will behave just like <command>svn
-          diff</command>.  (And conversely, the
+        <command>merge</command> 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
-        <literal>merge</literal> command.)</para>
+        <command>svn merge</command> command.)</para>
 
     </sect2>
 
@@ -1742,7 +1746,7 @@
         shuffle things around, then merge the branch back to the
         trunk, right?</para>
 
-      <para>Alas, this scenario doesn't work so well right now, and
+      <para>Alas, this scenario doesn't work so well right now and
         is considered one of Subversion's current weak spots.  The
         problem is that Subversion's <command>update</command>
         command isn't as robust as it should be, particularly when
@@ -1750,17 +1754,17 @@
 
       <para>When you use <command>svn copy</command> to duplicate a
         file, the repository remembers where the new file came from,
-        but it fails to transmit that information to the client
-        which is running <command>svn update</command>
-        or <command>svn merge</command>.  Instead of telling the
-        client, <quote>Copy that file you already have to this new
-          location</quote>, it instead sends down an entirely new
-        file.  This can lead to problems, especially because the
-        same thing happens with renamed files.  A lesser-known fact
-        about Subversion is that it lacks <quote>true
-          renames</quote>—the <command>svn move</command>
-        command is nothing more than an aggregation of <command>svn
-          copy</command> and <command>svn delete</command>.</para>
+        but it fails to transmit that information to the client which
+        is running <command>svn update</command> or <command>svn
+        merge</command>.  Instead of telling the client, <quote>Copy
+        that file you already have to this new location,</quote> it
+        instead sends down an entirely new file.  This can lead to
+        problems, especially because the same thing happens with
+        renamed files.  A lesser-known fact about Subversion is that
+        it lacks <quote>true renames</quote>—the <command>svn
+        move</command> command is nothing more than an aggregation
+        of <command>svn copy</command> and <command>svn
+        delete</command>.</para>
 
       <para>For example, suppose that while working on your private
         branch, you rename <filename>integer.c</filename>
@@ -1780,9 +1784,9 @@
       </screen>
 
       <para>This doesn't look so bad at first glance, but it's also
-        probably not what you or Sally expected.  The merge
-        operation has deleted the latest version
-        of <filename>integer.c</filename> file (the one containing
+        probably not what you or Sally expected.  The merge operation
+        has deleted the latest version of
+        the <filename>integer.c</filename> file (the one containing
         Sally's latest changes), and blindly added your
         new <filename>whole.c</filename> file—which is a
         duplicate of the <emphasis>older</emphasis> version
@@ -1790,7 +1794,7 @@
         merging your <quote>rename</quote> to the branch has removed
         Sally's recent changes from the latest revision!</para>
 
-      <para>This isn't true data-loss; Sally's changes are still in
+      <para>This isn't true data loss; Sally's changes are still in
         the repository's history, but it may not be immediately
         obvious that this has happened.  The moral of this story is
         that until Subversion improves, be very careful about
@@ -1805,8 +1809,8 @@
 
       <para>If you've just upgraded your server to Subversion 1.5 or
         later, then there's a significant risk that pre-1.5 Subversion
-        clients can mess up your merge-tracking.  Why is this?  When a
-        pre-1.5 Subversion client performs <command>svn
+        clients can mess up your automated merge tracking.  Why is
+        this?  When a pre-1.5 Subversion client performs <command>svn
         merge</command>, it doesn't modify the value of
         the <literal>svn:mergeinfo</literal> property at all.  So the
         subsequent commit, despite being the result of a merge,
@@ -1870,7 +1874,7 @@
     <para>After <quote>switching</quote> to the branch, your working
       copy is no different than what you would get from doing a fresh
       checkout of the directory.  And it's usually more efficient to
-      use this command, because often branches only differ by a small
+      use this command, because often branches differ only by a small
       degree.  The server sends only the minimal set of changes
       necessary to make your working copy reflect the branch
       directory.</para>
@@ -1881,7 +1885,7 @@
       <literal>HEAD</literal> of the branch.</para>
 
     <para>Of course, most projects are more complicated than our
-      <filename>calc</filename> example, containing multiple
+      <filename>calc</filename> example, and contain multiple
       subdirectories.  Subversion users often follow a specific
       algorithm when using branches:</para>
 
@@ -1896,8 +1900,8 @@
         </listitem>
       </orderedlist>
 
-    <para>In other words, if a user knows that the branch-work only
-      needs to happen on a specific subdirectory, they use
+    <para>In other words, if a user knows that the branch-work needs
+      only to happen on a specific subdirectory, they use
       <command>svn switch</command> to move only that subdirectory to
       the branch.  (Or sometimes users will switch just a single
       working file to the branch!)  That way, they can continue to
@@ -1935,15 +1939,15 @@
 
       <para>Have you noticed that the output of <command>svn
         switch</command> and <command>svn update</command> look the
-        same?  The <literal>switch</literal> command is actually a
-        superset of the update command.</para>
+        same?  The switch 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
-        <literal>update</literal> command always compares two identical
+        latter command always compares two identical repositoryx
         paths.</para>
 
       <para>That is, if your working copy is a mirror of
@@ -1955,7 +1959,7 @@
         working copy to a branch, then <command>svn switch</command>
         will compare your working copy of
         <filename>/calc/trunk</filename> to some
-        <emphasis>other</emphasis> branch-directory in the
+        <emphasis>other</emphasis> branch directory in the
         <literal>HEAD</literal> revision.</para>
 
       <para>In other words, an update moves your working copy through
@@ -1972,7 +1976,7 @@
       <tip>
         <para>Have you ever found yourself making some complex edits
           (in your <filename>/trunk</filename> working copy) and
-          suddenly realized, <quote>hey, these changes ought to be in
+          suddenly realized, <quote>Hey, these changes ought to be in
           their own branch?</quote>  A great technique to do this can
           be summarized in two steps:</para>
 
@@ -2009,8 +2013,8 @@
       after each commit.</para>
 
     <para>However, people often want to give more human-friendly names
-      to tags, like <literal>release-1.0</literal>.  And they want to
-      make snapshots of smaller subdirectories of the filesystem.
+      to tags, such as <literal>release-1.0</literal>.  And they want
+      to make snapshots of smaller subdirectories of the filesystem.
       After all, it's not so easy to remember that release-1.0 of a
       piece of software is a particular subdirectory of revision
       4822.</para>
@@ -2062,16 +2066,16 @@
         approaches you can take to managing tags.  The first approach
         is <quote>hands off</quote>: as a matter of project policy,
         decide where your tags will live, and make sure all users know
-        how to treat the directories they copy in there.  (That is,
-        make sure they know not to commit to them.)  The second
-        approach is more paranoid: you can use one of the
-        access-control scripts provided with Subversion to prevent
-        anyone from doing anything but creating new copies in the
-        tags-area (See <xref linkend="svn.serverconfig"/>.)  The paranoid
-        approach, however, isn't usually necessary.  If a user
-        accidentally commits a change to a tag-directory, you can
-        simply undo the change as discussed in the previous section.
-        This is version control, after all!</para>
+        how to treat the directories they copy.  (That is, make sure
+        they know not to commit to them.)  The second approach is more
+        paranoid: you can use one of the access-control scripts
+        provided with Subversion to prevent anyone from doing anything
+        but creating new copies in the tags area (see
+        <xref linkend="svn.serverconfig"/>).  The paranoid approach,
+        however, isn't usually necessary.  If a user accidentally
+        commits a change to a tag directory, you can simply undo the
+        change as discussed in the previous section.  This is version
+        control, after all!</para>
 
     </sect2>
 
@@ -2090,7 +2094,7 @@
         copy that is designed to have specific features and bug fixes.
         You can accomplish this by selectively backdating files or
         directories to particular revisions (using <command>svn update
-        -r</command> liberally), or by switching files and directories
+        -r</command> liberally) or by switching files and directories
         to particular branches (making use of <command>svn
         switch</command>).  When you're done, your working copy is a
         hodgepodge of repository locations from different revisions.
@@ -2124,11 +2128,11 @@
         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, symlink changes or changes in properties), you can
+        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 check out a verbatim copy of your
-        working copy, or use <command>svn merge</command> to receive
+        working copy or use <command>svn merge</command> to receive
         your exact changes.</para>
 
       <para>While this is a nice method for uploading a quick snapshot
@@ -2260,7 +2264,7 @@
         short lifetime: you may have created it to fix a bug or
         implement a new feature.  When your task is done, so is the
         branch.  In software development, though, it's also common to
-        have two <quote>main</quote> branches running side-by-side for
+        have two <quote>main</quote> branches running side by side for
         very long periods.  For example, suppose it's time to release
         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
@@ -2301,8 +2305,8 @@
     <title>Common Branching Patterns</title>
 
     <para>There are many different uses for branching and <command>svn
-        merge</command>, and this section describes the most common ones
-      you're likely to run into.</para>
+        merge</command>, and this section describes the most
+        common.</para>
 
     <para>Version control is most often used for software
       development, so here's a quick peek at two of the most common
@@ -2323,7 +2327,7 @@
       <para>Most software has a typical lifecycle: code, test,
         release, repeat.  There are two problems with this process.
         First, developers need to keep writing new features while
-        quality-assurance teams take time to test supposedly-stable
+        quality-assurance teams take time to test supposedly stable
         versions of the software.  New work cannot halt while the
         software is tested.  Second, the team almost always needs to
         support older, released versions of software; if a bug is
@@ -2335,7 +2339,7 @@
       <para>Here's where version control can help.  The typical
         procedure looks like this:</para>
 
-      <itemizedlist>
+      <orderedlist>
 
         <listitem>
           <para><emphasis>Developers commit all new work to the
@@ -2391,7 +2395,7 @@
             is packaged and released.</para>
         </listitem>
 
-      </itemizedlist>
+      </orderedlist>
 
       <para>This entire process repeats as the software matures:
         when the 2.0 work is complete, a new 2.0 release branch is
@@ -2407,15 +2411,15 @@
       <title>Feature Branches</title>
 
       <para>A <firstterm>feature branch</firstterm> is the sort of
-        branch that's been the dominant example in this chapter, the
+        branch that's been the dominant example in this chapter (the
         one you've been working on while Sally continues to work on
-        <filename>/trunk</filename>.  It's a temporary branch
-        created to work on a complex change without interfering with
-        the stability of <filename>/trunk</filename>.  Unlike
-        release branches (which may need to be supported forever),
-        feature branches are born, used for a while, merged back to
-        the trunk, then ultimately deleted.  They have a finite span
-        of usefulness.</para>
+        <filename>/trunk</filename>).  It's a temporary branch created
+        to work on a complex change without interfering with the
+        stability of <filename>/trunk</filename>.  Unlike release
+        branches (which may need to be supported forever), feature
+        branches are born, used for a while, merged back to the trunk,
+        then ultimately deleted.  They have a finite span of
+        usefulness.</para>
 
       <para>Again, project policies vary widely concerning exactly
         when it's appropriate to create a feature branch.  Some
@@ -2427,7 +2431,7 @@
         projects use branches to an extreme: no change is
         <emphasis>ever</emphasis> committed to the trunk directly.
         Even the most trivial changes are created on a short-lived
-        branch, carefully reviewed and merged to the trunk.  Then
+        branch, carefully reviewed, and merged to the trunk.  Then
         the branch is deleted.  This system guarantees an
         exceptionally stable and usable trunk at all times, but at
         the cost of tremendous process overhead.</para>
@@ -2441,7 +2445,7 @@
         then committed the large change all at once (so that
         <filename>/trunk</filename> were never destabilized), would it
         be too large a change to review?  If the answer to that
-        question is <quote>yes</quote>, then the change should be
+        question is <quote>yes,</quote> then the change should be
         developed on a feature branch.  As the developer commits
         incremental changes to the branch, they can be easily reviewed
         by peers.</para>
@@ -2497,24 +2501,24 @@
   <!-- ================================================================= -->
   <!-- ================================================================= -->
   <sect1 id="svn.advanced.vendorbr">
-    <title>Vendor branches</title>
+    <title>Vendor Branches</title>
 
     <para>As is especially the case when developing software, the data
       that you maintain under version control is often closely related
       to, or perhaps dependent upon, someone else's data.  Generally,
       the needs of your project will dictate that you stay as
-      up-to-date as possible with the data provided by that external
+      up to date as possible with the data provided by that external
       entity without sacrificing the stability of your own project.
       This scenario plays itself out all the time—anywhere that
       the information generated by one group of people has a direct
       effect on that which is generated by another group.</para>
 
     <para>For example, software developers might be working on an
-      application which makes use of a third-party library.
-      Subversion has just such a relationship with the Apache Portable
-      Runtime library (see <xref linkend="svn.developer.usingapi.apr" />).  The
-      Subversion source code depends on the APR library for all its
-      portability needs.  In earlier stages of Subversion's
+      application that makes use of a third-party library.  Subversion
+      has just such a relationship with the Apache Portable Runtime
+      library (see <xref linkend="svn.developer.usingapi.apr" />).
+      The Subversion source code depends on the APR library for all
+      its portability needs.  In earlier stages of Subversion's
       development, the project closely tracked APR's changing API,
       always sticking to the <quote>bleeding edge</quote> of the
       library's code churn.  Now that both APR and Subversion have
@@ -2549,7 +2553,7 @@
       disjointed fashion, such as using patch files or full-fledged
       alternate versions of files and directories.  But these quickly
       become maintenance headaches, requiring some mechanism by which
-      to apply your custom changes to the third-party code, and
+      to apply your custom changes to the third-party code and
       necessitating regeneration of those changes with each successive
       version of the third-party code that you track.</para>
 
@@ -2577,12 +2581,12 @@
       <para>Managing vendor branches generally works like this: first,
         you create a top-level directory (such as
         <filename>/vendor</filename>) to hold the vendor branches.
-        Then you import the third party code into a subdirectory of
+        Then you import the third-party code into a subdirectory of
         that top-level directory.  You then copy that subdirectory
         into your main development branch (for example,
         <filename>/trunk</filename>) at the appropriate location.  You
         always make your local changes in the main development branch.
-        With each new release of the code you are tracking you bring
+        With each new release of the code you are tracking, you bring
         it into the vendor branch and merge the changes into
         <filename>/trunk</filename>, resolving whatever conflicts
         occur between your local changes and the upstream
@@ -2592,14 +2596,14 @@
         a scenario where your development team is creating a
         calculator program that links against a third-party complex
         number arithmetic library, libcomplex.  We'll begin with the
-        initial creation of the vendor branch, and the import of the
+        initial creation of the vendor branch and the import of the
         first vendor drop.  We'll call our vendor branch directory
         <filename>libcomplex</filename>, and our code drops will go
         into a subdirectory of our vendor branch called
         <filename>current</filename>.  And since <command>svn
         import</command> creates all the intermediate parent
         directories it needs, we can actually accomplish both of these
-        steps with a single command.</para>
+        steps with a single command:</para>
 
       <screen>
 $ svn import /path/to/libcomplex-1.0 \
@@ -2616,7 +2620,7 @@
         <filename>libcomplex</filename> in our existing
         <filename>calc</filename> project directory.  It is in this
         copied version of the vendor data that we will make our
-        customizations.</para>
+        customizations:</para>
 
       <screen>
 $ svn copy http://svn.example.com/repos/vendor/libcomplex/current  \
@@ -2653,13 +2657,13 @@
         modified copy of it.</para>
 
       <para>To perform this upgrade, we check out a copy of our vendor
-        branch, and replace the code in the
+        branch and replace the code in the
         <filename>current</filename> directory with the new libcomplex
         1.1 source code.  We quite literally copy new files on top of
         existing files, perhaps exploding the libcomplex 1.1 release
         tarball atop our existing files and directories.  The goal
         here is to make our <filename>current</filename> directory
-        contain only the libcomplex 1.1 code, and to ensure that all
+        contain only the libcomplex 1.1 code and to ensure that all
         that code is under version control.  Oh, and we want to do
         this with as little version control history disturbance as
         possible.</para>
@@ -2685,7 +2689,7 @@
         way we previously tagged the version 1.0 vendor drop), and
         then merge the differences between the tag of the previous
         version and the new current version into our main development
-        branch.</para>
+        branch:</para>
 
       <screen>
 $ cd working-copies/calc
@@ -2700,7 +2704,7 @@
       <para>In the trivial use case, the new version of our
         third-party tool would look, from a files-and-directories
         point of view, just like the previous version.  None of the
-        libcomplex source files would have been deleted, renamed or
+        libcomplex source files would have been deleted, renamed, or
         moved to different locations—the new version would
         contain only textual modifications against the previous one.
         In a perfect world, our modifications would apply cleanly to
@@ -2711,14 +2715,14 @@
         quite common for source files to get moved around between
         releases of software.  This complicates the process of
         ensuring that our modifications are still valid for the new
-        version of code, and can quickly degrade into a situation
-        where we have to manually recreate our customizations in the
-        new version.  Once Subversion knows about the history of a
-        given source file—including all its previous
-        locations—the process of merging in the new version of
-        the library is pretty simple.  But we are responsible for
-        telling Subversion how the source file layout changed from
-        vendor drop to vendor drop.</para>
+        version of code, and things can quickly degrade into a
+        situation where we have to manually recreate our
+        customizations in the new version.  Once Subversion knows
+        about the history of a given source file—including all
+        its previous locations—the process of merging in the new
+        version of the library is pretty simple.  But we are
+        responsible for telling Subversion how the source file layout
+        changed from vendor drop to vendor drop.</para>
 
     </sect2>
 
@@ -2729,10 +2733,10 @@
 
     <!-- =============================================================== -->
     <sect2 id="svn.advanced.vendorbr.svn_load_dirs">
-      <title><command>svn_load_dirs.pl</command></title>
+      <title>svn_load_dirs.pl</title>
 
       <para>Vendor drops that contain more than a few deletes,
-        additions and moves complicate the process of upgrading to
+        additions, and moves complicate the process of upgrading to
         each successive version of the third-party data.  So
         Subversion supplies the <command>svn_load_dirs.pl</command>
         script to assist with this process.  This script automates the
@@ -2801,7 +2805,7 @@
 
       <para>When you run <command>svn_load_dirs.pl</command>, it
         examines the contents of your existing <quote>current</quote>
-        vendor drop, and compares them with the proposed new vendor
+        vendor drop and compares them with the proposed new vendor
         drop.  In the trivial case, there will be no files that are in
         one version and not the other, and the script will perform the
         new import without incident.  If, however, there are
@@ -2862,11 +2866,11 @@
     <title>Summary</title>
 
     <para>We've covered a lot of ground in this chapter.  We've
-      discussed the concepts of tags and branches, and demonstrated
+      discussed the concepts of tags and branches and demonstrated
       how Subversion implements these concepts by copying directories
       with the <command>svn copy</command> command.  We've shown how
       to use <command>svn merge</command> to copy changes from one
-      branch to another, or roll back bad changes.  We've gone over
+      branch to another or roll back bad changes.  We've gone over
       the use of <command>svn switch</command> to create
       mixed-location working copies.  And we've talked about how one
       might manage the organization and lifetimes of branches in a
@@ -2876,11 +2880,11 @@
       So use them liberally!</para>
 
     <para>As a helpful reminder of all the operations we've discussed,
-      here's a handy reference table you can consult as you begin to
-      make use of branches.</para>
+      the following table is a handy reference that you can consult as
+      you begin to make use of branches.</para>
 
     <table id="svn.branchemerge.summary.tbl-1">
-      <title>Branching and Merging Commands</title>
+      <title>Branching and merging commands</title>
       <tgroup cols="2">
         <thead>
           <row>




More information about the svnbook-dev mailing list