[svnbook commit] r2839 - trunk/src/en/book
sussman
noreply at red-bean.com
Sun Aug 12 21:29:15 CDT 2007
Author: sussman
Date: Sun Aug 12 21:29:15 2007
New Revision: 2839
Log:
Fix trac issue 29, partially.
* src/en/book/ch04-branching-and-merging.xml
(svn.branchmerge.copychanges.bestprac.preview): tweak some wording.
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 Aug 12 21:29:15 2007
@@ -804,10 +804,10 @@
<para>What does this mean to you, the user? It means that
until the day Subversion grows this feature, you'll have to
track merge information yourself. The best place to do this
- is in the commit log-message. As demonstrated in the
- earlier example, it's recommended that your log-message
- mention a specific revision number (or range of revisions)
- that are being merged into your branch. Later on, you can
+ is in the commit log-message. As demonstrated in prior
+ examples, it's recommended that your log-message mention a
+ specific revision number (or range of revisions) that are
+ being merged into your branch. Later on, you can
run <command>svn log</command> to review which changes your
branch already contains. This will allow you to carefully
construct a subsequent <command>svn merge</command> command
@@ -823,14 +823,20 @@
<sect3 id="svn.branchmerge.copychanges.bestprac.preview">
<title>Previewing Merges</title>
- <para>Because merging only results in local modifications,
- it's not usually a high-risk operation. If you get the
- merge wrong the first time, simply <command>svn
- revert</command> the changes and try again.</para>
-
- <para>It's possible, however, that your working copy might
- already have local modifications. The changes applied by a
- merge will be mixed with your pre-existing ones, and running
+ <para>First: always remember 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 headaches.</para>
+
+ <para>Assuming your working copy is tidy, merging isn't a
+ particularly high-risk operation. If you get the merge
+ wrong the first time, simply <command>svn revert</command>
+ the changes and try again.</para>
+
+ <para>If you've merged into a working copy that already has
+ local modifications, the changes applied by a merge will be
+ mixed with your pre-existing ones, and running
<command>svn revert</command> is no longer an option. The
two sets of changes may be impossible to separate.</para>
More information about the svnbook-dev
mailing list