[svnbook] r4359 committed - * en/book/ch04-branching-and-merging.xml:...
svnbook at googlecode.com
svnbook at googlecode.com
Thu Jan 24 16:01:31 CST 2013
Revision: 4359
Author: ptburba
Date: Thu Jan 24 14:00:59 2013
Log: * en/book/ch04-branching-and-merging.xml:
Chapter-wide tweaks to reflect the fact the the current
release will be 1.8, not 1.7, when this version of the
book is branched.
http://code.google.com/p/svnbook/source/detail?r=4359
Modified:
/trunk/en/book/ch04-branching-and-merging.xml
=======================================
--- /trunk/en/book/ch04-branching-and-merging.xml Tue Jan 22 15:34:56 2013
+++ /trunk/en/book/ch04-branching-and-merging.xml Thu Jan 24 14:00:59 2013
@@ -464,7 +464,7 @@
merge</command> subcommand.</para>
<para>In the examples that follow, we're assuming that both your
- Subversion client and server are running Subversion 1.7 (or
+ Subversion client and server are running Subversion 1.8 (or
later). If either client or server is older than version 1.5,
things are more complicated: the system won't track changes
automatically, forcing you to use painful manual methods to
@@ -490,8 +490,8 @@
releases of Subversion introduced many enhancements and bug
fixes to merge tracking, which is why we recommend using the
most recent versions for both your server and client. Keep in
- mind that even if your server is running 1.5 or 1.6, you can still
- use a 1.7 client. This is particularly important with regard to
merge
+ mind that even if your server is running 1.5-1.7, you can still
+ use a 1.8 client. This is particularly important with regard to
merge
tracking, because the overwhelming majority of fixes to it are on
the client side.</para>
</sidebar>
@@ -977,8 +977,8 @@
resulted in changes to every subtree with mergeinfo, even
those that were not parents of the affected path(s). This
caused some level of confusion and frustration. Subversion 1.7
- addresses this problem by only updating the mergeinfo on
- subtrees which are parents of the paths modified by the merge
+ and later addresses this problem by only updating the mergeinfo
+ on subtrees which are parents of the paths modified by the merge
(i.e. paths changed, added, or deleted by application of the
difference, see
<xref linkend="svn.branchmerge.advanced.advancedsyntax"/>).
@@ -999,7 +999,7 @@
branch changes back to the trunk (so your team can enjoy the
bounty of your labor). The process is simple. First, bring
your branch into sync with the trunk again, just as you've been
- doing all along<footnote><para>With Subversion 1.7 you don't
+ doing all along<footnote><para>Since Subversion 1.7 you don't
absolutely have to do all your sync merges to the root of your
branch as we do in this example. <emphasis>If</emphasis> your
branch is effectively synced via a series of subtree
@@ -1231,9 +1231,9 @@
still detect the changes, after a merge completed, with the
<command>svn diff</command> or <command>svn status</command>
subcommands, but the merge itself gave no indication when it
- changed the <literal>svn:mergeinfo</literal> property. This is no
- longer true in Subversion 1.7, which has several new notifications
- to alert you when a merge updates the
+ changed the <literal>svn:mergeinfo</literal> property. In
+ Subversion 1.7 and later this is no longer true as there are
+ several notifications to alert you when a merge updates the
<literal>svn:mergeinfo</literal> property. These notifications
all begin with <quote>--- Recording mergeinfo for</quote>
and appear at the end of the merge. Unlike other merge
@@ -1375,7 +1375,7 @@
<xref linkend="svn.branchmerge.advanced.finalword"/></para>
</sidebar>
- <para>With the release of Subversion 1.7, the
+ <para>Since Subversion 1.7, the
<command>svn mergeinfo</command> subcommand can also account for
subtree mergeinfo and non-inheritable mergeinfo. It accounts for
subtree mergeinfo by use of the <option>--recursive</option> or
@@ -2310,10 +2310,9 @@
out, that is, prevent them from ever being automatically
merged.</para>
- <para>Through Subversion 1.7, the only way to block a changeset
- is to make the system believe that the change has
- <emphasis>already</emphasis> been merged. To do this, invoke
- the merge subcommand with the <option>--record-only</option>
+ <para>To block a changeset you must make Subversion believe that the
+ change has <emphasis>already</emphasis> been merged. To do this,
+ invoke the merge subcommand with the <option>--record-only</option>
option:</para>
<informalexample>
@@ -2339,7 +2338,7 @@
</screen>
</informalexample>
- <para>Beginning with Subversion 1.7, <option>--record-only</option>
+ <para>Since Subversion 1.7, <option>--record-only</option>
merges are transitive. This means that, in addition to recording
mergeinfo describing the blocked revision(s), any
<literal>svn:mergeinfo</literal> property differences in the
@@ -2386,13 +2385,13 @@
merge r996:1003 directly from
<filename>^/branches/frazzle-feature-branch</filename>.
Fortunately the transitive nature
- of <option>--record-only</option> merges in Subversion 1.7
- prevents this; the <option>--record-only</option> merge
+ of <option>--record-only</option> merges prevents this; the
+ <option>--record-only</option> merge
applies the <literal>svn:mergeinfo</literal> diff from
- revision 1055, thus blocking merges directly from the frazzle
- branch <emphasis>and</emphasis> as it has always done prior to
- Subversion 1.7, it blocks merges of revision 1055 directly
- from <filename>^/trunk</filename>:</para>
+ revision 1055, thus blocking merges of that change directly from
+ <filename>^/trunk</filename> <emphasis>and</emphasis> indirectly
+ from <filename>^/branches/frazzle-feature-branch</filename>:
+ </para>
<informalexample>
<screen>
@@ -3081,8 +3080,8 @@
(via the <literal>RedirectPermanent</literal> directive).
Subversion clients will generally display the new repository
URL in error messages generated when the user attempts to use
- working copies which still reflect the old URL location. In
- fact, Subversion 1.7 clients will go a step further,
+ working copies which still reflect the old URL location. Since
+ Subversion 1.7 clients will go a step further,
automatically relocating the working copy to the new
URL.</para>
</tip>
More information about the svnbook-dev
mailing list