> 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