[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Release Notes: Information on the "natural history" currently present in svn:mergeinfo

From: Marc Strapetz <marc.strapetz_at_syntevo.com>
Date: Wed, 04 Jun 2008 10:44:49 +0200

> I can't think of a (recommended) case where normal merges are repeatedly
> performed from a descendant branch back to its parent. We may just have
> to cite the non-recommended case, and emphasize that it is not
> recommended.

Karl, please find a suggested patch attached.

--
Best regards,
Marc Strapetz
_____________
SyntEvo GmbH
www.syntevo.com
Karl Fogel wrote:
> Marc Strapetz <marc.strapetz_at_syntevo.com> writes:
>> We are fixing bugs directly in the release branch and from time to
>> time are merging these revisions back to the trunk (this was the
>> situation I had in mind when changing the release notes). Here the
>> natural history problem becomes apparent.
> 
> Ah. "Standard practice" is, I think, to fix such things on trunk and
> merge the fixes out to the branches.  At least, that's what we always do
> for Subversion itself.
> 
> Obviously, it would be best if merge-tracking worked smoothly for both
> Ways.  For now, I think we should just document that doing it this way
> is recommended and will avoid issue #3157.
> 
>> Maybe there is another typical use case where "normal" merges are
>> performed from a descendant branch back to its parent which could be
>> used to illustrate the problem in the release notes?
> 
> I can't think of a (recommended) case where normal merges are repeatedly
> performed from a descendant branch back to its parent.  We may just have
> to cite the non-recommended case, and emphasize that it is not
> recommended.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
> 
> 

Index: www/svn_1.5_releasenotes.html
===================================================================
--- www/svn_1.5_releasenotes.html (revision 31577)
+++ www/svn_1.5_releasenotes.html (working copy)
@@ -476,32 +476,31 @@
 #3157</a> for more details.]</p>
 
 <p>Merge tracking information currently can include the "natural
-history" of a path. One situation where this happens is when creating
-a <tt>branch</tt> from <tt>trunk</tt> at a certain revision <tt>X</tt>
-and later merging all changes from <tt>branch</tt> back to
-<tt>trunk</tt>, without explicitly limiting the merge range and
-without using the recommended <a href="#mt-reintegrate"
-><code>--reintegrate</code> option</a>. Afterwards, the merge
-tracking information on <tt>trunk</tt> will list revisions before
-<tt>X</tt>. This does no harm to future merge operations, but
-thereafter <code>svn log -g</code> on <tt>trunk</tt> will report these
-revisions from the "natural history", which is typically not expected.
-This is because <code>svn log -g</code> uses the merge tracking
-information from previous revisions (not only from HEAD).</p>
+history" of a path. One such scenario where this happens is
+when creating a release <tt>branch</tt> from <tt>trunk</tt>
+at a certain revision <tt>X</tt> and later merging all changes
+from <tt>branch</tt> back to <tt>trunk</tt>, without explicitly
+limiting the merge range. Please note that this is not the
+recommended usage of a release branch (revisions should never be
+merged back from a release branch), anyway, it leads to following
+problem: The merge tracking information on <tt>trunk</tt> will now
+list revisions before <tt>X</tt>. This does no harm to future merge
+operations, but thereafter <code>svn log -g</code> on <tt>trunk</tt> will
+report these revisions from the "natural history", which is typically
+not expected.</p>
 
-<p>One workaround is to correct the merge tracking information before
-committing the merged revision, by reverse merging the "natural
-history" information: <code>svn merge --record-only -rX:1</code>.
+<p>Because <code>svn log -g</code> uses the merge tracking information
+from previous revisions (not only from HEAD), the problem has to be
+corrected before committing the merged revision:
+One solution is to correct the merge tracking information directly
+after the merge by reverse merging the "natural history" information:
+<code>svn merge --record-only -rX:1</code>.
 Another solution is to avoid this situation entirely, by explicitly
 specifying merge ranges in the first place, e.g.: <tt>-rX:HEAD</tt>.
 See <a
 href="http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=139379"
>this mail</a> for more information.</p>
 
-<p>The best solution is to to <a href="#mt-reintegrate" >use the
-<code>--reintegrate</code> option</a>. If you do, the above problem
-won't happen.</p>
-
 </div> <!-- mt-known-limitations -->
 
 <div class="h4" id="mt-further-reading" title="mt-further-reading">

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-04 10:45:10 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.