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

kfogel noreply at red-bean.com
Thu Apr 24 12:25:42 CDT 2008


Author: kfogel
Date: Thu Apr 24 12:25:42 2008
New Revision: 3040

Log:
* src/en/book/ch04-branching-and-merging.xml
  (Changesets): Use the standard "rN" syntax for revision numbers.
  (Keeping a Branch in Sync): Don't change verb subject in mid-sentence.
    Say "these changes", not "your changes", because the changes in
    question were by someone else and only merged to "your" branch.
    Add an extra update step in example, to emphasize the point.
    Clarify some things by introducing the term "line of development".
  (Mergeinfo and Previews): Don't claim we saw 'svn mergeinfo'
    earlier, since this is actually the first mention of it.


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	Thu Apr 24 12:25:42 2008
@@ -500,7 +500,7 @@
         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
+        <quote>this issue was fixed by r9238.</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.
@@ -509,7 +509,7 @@
         revision numbers.  You can merge specific changesets from one
         branch to another by naming them in the merge
         arguments: <command>svn merge -c 9238</command> would merge
-        changeset #9238 into your working copy.</para>
+        changeset r9238 into your working copy.</para>
 
       </sect2>
 
@@ -525,8 +525,8 @@
         project's <filename>/trunk</filename>.  It's in your best
         interest to replicate those changes to your own branch, just
         to make sure they mesh well with your changes.  In fact, this
-        is a best practice: by frequently keeping your branch in sync
-        with the main development line, it helps
+        is a best practice: frequently keeping your branch in sync
+        with the main development line helps
         prevent <quote>surprise</quote> conflicts when it comes time
         for you to fold your changes back into the trunk.</para>
 
@@ -571,7 +571,7 @@
         changes by running <command>svn revert</command> and start a
         long <quote>what's going on?</quote> discussion with your
         collaborators.  If things look good, however, then you can
-        submit your changes into the repository:</para>
+        submit these changes into the repository:</para>
 
       <screen>
 $ svn commit -m "Merged latest trunk changes to my-calc-branch."
@@ -702,6 +702,9 @@
 $ pwd
 /home/user/calc-trunk
 
+$ svn update  # (just to make sure the working copy is at latest everywhere)
+At revision 390.
+
 $ svn merge --reintegrate http://svn.example.com/repos/calc/branches/my-calc-branch
 --- Merging r341 through r390 into '.':
 U    button.c
@@ -725,8 +728,9 @@
         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 from one branch and duplicate them to
-        another.  This is fairly straightforward, and each time
+        set</quote> of changes from one line of development (the
+        trunk) and duplicate them to another (your branch).  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,8 +751,7 @@
 
       <para>Now that your branch is merged to trunk, you'll no longer
         need your branch.  You can destroy your working copy of the
-        branch, and also do some basic housecleaning in the
-        repository:</para>
+        branch, and also remove it from the repository:</para>
 
       <screen>
 $ svn delete http://svn.example.com/repos/calc/branches/my-calc-branch
@@ -800,7 +803,7 @@
         its value indicates which changes have already been replicated
         into a particular directory.</para>
 
-      <para>As we saw earlier, there's also a subcommand <command>svn
+      <para>There's also a subcommand <command>svn
         mergeinfo</command>, which can be helpful in seeing not only
         which changesets a directory has absorbed, but also which
         changesets it's still eligible to receive.  This gives a sort




More information about the svnbook-dev mailing list