[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