[svnbook] r3893 committed - * src/en/book/ch04-branching-and-merging.xml...
svnbook at googlecode.com
svnbook at googlecode.com
Thu Jul 7 13:38:25 CDT 2011
Revision: 3893
Author: cmpilato at gmail.com
Date: Thu Jul 7 11:37:35 2011
Log: * src/en/book/ch04-branching-and-merging.xml
Markup corrections only.
http://code.google.com/p/svnbook/source/detail?r=3893
Modified:
/trunk/src/en/book/ch04-branching-and-merging.xml
=======================================
--- /trunk/src/en/book/ch04-branching-and-merging.xml Thu Jul 7 09:39:18
2011
+++ /trunk/src/en/book/ch04-branching-and-merging.xml Thu Jul 7 11:37:35
2011
@@ -1609,37 +1609,47 @@
</varlistentry>
</variablelist>
- <sidebar>
- <title>Natural History and Implicit Mergeinfo</title>
-
- <para>When a path has the <literal>svn:mergeinfo</literal>
- property set on it we speak of it as having 'explicit' mergeinfo.
- Yes, this implies a path can have 'implicit' mergeinfo! Implicit
- mergeinfo, sometimes called 'natural history', is simply a path's
- own history (see <xref linkend="svn.tour.history"/>) interpreted
- as mergeinfo. While implicit mergeinfo is largely an
- implementation detail, it can be a useful abstraction for
- understanding merge tracking behavior.</para>
- <para>Let's say you created <literal>^/trunk</literal> in revision
- 100 and then copied <literal>^/trunk at 200</literal> to
- <literal>^/branches/feature-branch-1</literal> in revision 201.
- The implicit mergeinfo of <literal>^/branches/feature-branch-1
- </literal> is then:</para>
- <screen>
+ <sidebar>
+ <title>Natural History and Implicit Mergeinfo</title>
+
+ <para>When a path has the <literal>svn:mergeinfo</literal>
+ property set on it we speak of it as
+ having <quote>explicit</quote> mergeinfo. Yes, this implies
+ a path can have <quote>implicit</quote> mergeinfo! Implicit
+ mergeinfo, sometimes called <quote>natural history</quote>,
+ is simply a path's own history (see
+ <xref linkend="svn.tour.history" />) interpreted as
+ mergeinfo. While implicit mergeinfo is largely an
+ implementation detail, it can be a useful abstraction for
+ understanding merge tracking behavior.</para>
+
+ <para>Let's say you created <literal>^/trunk</literal> in
+ revision 100 and then copied <literal>^/trunk at 200</literal>
+ to <literal>^/branches/feature-branch-1</literal> in
+ revision 201. The implicit mergeinfo
+ of <literal>^/branches/feature-branch-1</literal> is
+ then:</para>
+
+ <informalexample>
+ <literallayout>
/trunk:100-200
-/branches/feature-branch-1:201</screen>
+/branches/feature-branch-1:201
+</literallayout>
+ </informalexample>
+
<para>Implicit mergeinfo does not actually show up in the
- <literal>svn:mergeinfo</literal> property, but Subversion acts
- like it does. That is why if you checked out
- <literal>^/branches/feature-branch-1 at 201</literal> and tried
- the following merge nothing would happen:</para>
- <screen>
-svn merge ^/trunk feature-branch-working-copy -c 58</screen>
- <para>Subversion sees that revision 58 of
- <literal>^/trunk</literal> is already present in the target's
- natural history so it doesn't repeat the merge (avoiding repeat
- merges being a primary goal of merge tracking).</para>
- </sidebar>
+ <literal>svn:mergeinfo</literal> property, but Subversion
+ acts like it does. That is why if you checked out
+ <literal>^/branches/feature-branch-1 at 201</literal> and then
+ ran <userinput>svn merge ^/trunk -c 58</userinput> in the
+ resulting working copy, nothing would happen. Subversion sees
+ that revision 58 of
+ <literal>^/trunk</literal> is already present in the
+ target's natural history so it doesn't repeat the merge
+ (avoiding repeat merges being a primary goal of merge
+ tracking).</para>
+
+ </sidebar>
</sect2>
More information about the svnbook-dev
mailing list