You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by st...@apache.org on 2013/05/02 17:15:25 UTC

svn commit: r1478406 - /subversion/site/publish/faq.html

Author: stsp
Date: Thu May  2 15:15:25 2013
New Revision: 1478406

URL: http://svn.apache.org/r1478406
Log:
* publish/faq.html: Add a new entry documenting when and why 'svn copy'
   will create mergeinfo on the copy target.

Modified:
    subversion/site/publish/faq.html

Modified: subversion/site/publish/faq.html
URL: http://svn.apache.org/viewvc/subversion/site/publish/faq.html?rev=1478406&r1=1478405&r2=1478406&view=diff
==============================================================================
--- subversion/site/publish/faq.html (original)
+++ subversion/site/publish/faq.html Thu May  2 15:15:25 2013
@@ -144,6 +144,7 @@ to FSFS or from FSFS to BDB?</a></li>
     "vendor branch") of third-party software using Subversion?</a></li>
 <li><a href="#undo">How do I make the contents of a previous
   revision become HEAD again?</a></li>
+<li><a href="#copy-mergeinfo">When does <tt>svn copy</tt> create <tt>svn:mergeinfo</tt> properties, and why?<a/></li>
 </ul>
 
 <h4>Troubleshooting:</h4>
@@ -2535,6 +2536,53 @@ href="http://svnbook.red-bean.com/nightl
 
 </div>
 
+<div class="h3" id="copy-mergeinfo">
+
+<h3>When does <tt>svn copy</tt> create <tt>svn:mergeinfo</tt> properties, and why?
+  <a class="sectionlink" href="#copy-mergeinfo"
+    title="Link to this section">&para;</a>
+</h3>
+
+<p>In general, to avoid some kinds of spurious merge conflicts,
+the following rules can be kept in mind:</p>
+
+<ul>
+  <li>When copying/renaming a file or directory <em>within</em> the trunk
+      or a branch, perform the copy/rename in a working copy. For renames,
+      the working copy should <em>not</em> be a <a
+      href="http://svnbook.red-bean.com/nightly/en/svn.basic.in-action.html#svn.basic.in-action.mixedrevs"
+      >mixed-revision working copy</a>.</li>
+  <li>When copying/renaming an entire branch, perform the copy/rename in
+      the repository (i.e. via URLs).</li>
+</ul>
+
+<p>During copies where the source is a URL, and the target is either a URL
+or in a working copy, explicit mergeinfo is created on the copy target.
+This is done so that when a branch is created with
+<pre>svn copy ^/trunk ^/branches/mybranch</pre>
+and later an ancestrally unrelated subtree is copied into the branch using
+an invocation such as
+<pre>svn copy ^/branches/another-branch/foo ^/branches/mybranch/bar</pre>
+the directory <tt>/branches/mybranch/bar</tt> does not inherit mergeinfo
+from its parent <tt>/branches/mybranch</tt>. Mergeinfo inherited from the
+parent might not reflect the factually correct merge history of the new
+child.</p>
+
+<p>During copies where both the source and the target are within a working
+copy, no mergeinfo is created on the copy target (as of Subversion 1.5.5).
+This assumes the case where a new child is added on the trunk (or a branch),
+and this addition is merged to another branch which is kept in sync using
+periodic catch-up merges. In this case, the inherited mergeinfo of the
+branch's new child is correct, and the creation of explicit mergeinfo could
+cause spurious merge conflicts due to apparent, but factually inaccurate,
+differences in the child's and parent's merge histories.</p>
+
+<p>For additional details and discussion about this behaviour, see
+<a href="http://mail-archives.apache.org/mod_mbox/subversion-users/201011.mbox/%3CAANLkTin0xJwxg78rU-83QafOt-bcfgML_pB2AHWt2z1s%40mail.gmail.com%3E"
+>this post on the users mailing list</a>.</p>
+
+</div>
+
 </div>
 
 <div class="h2" id="troubleshooting">