[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