[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 20:22:53 +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.
>
> I made a similar tweak in r31582, tell me what you think.

I would suggest to rearrange some sentences so there is a clear order,
starting with the description of the problem, continuing with the
resolution and finishing with the non-problematical cases.

I have also moved

"This is because <code>svn log -g</code> uses the merge tracking
information from previous revisions (not only from HEAD)"

to the second paragraph, because the problem isn't that log -g uses
non-HEAD revision, but that non-HEAD revisions can't be corrected anymore.

--
Best regards,
Marc Strapetz
_____________
SyntEvo GmbH
www.syntevo.com
Karl Fogel wrote:
> Marc Strapetz <marc.strapetz_at_syntevo.com> writes:
>>> 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.
> 
> I made a similar tweak in r31582, tell me what you think.
> 
> -K
> 
> ---------------------------------------------------------------------
> 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 31590)
+++ www/svn_1.5_releasenotes.html (working copy)
@@ -485,28 +485,25 @@
 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>
+revisions from the "natural history", which is typically not expected.</p>
 
-<p>Note that this should not be a problem with release branches (also
-called "maintenance branches"), because one typically does not merge
-them back to trunk. Instead, recommended practice is for new changes
-to enter on trunk and be ported outward to the branches that need the
-changes. However, you could run into this problem with a feature
-branch, which would be merged back to trunk once, at the end of the
-branch's lifetime.</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), this
+problem has to be corrected before committing the merged revision
+(otherwise it will be irrevocably present in the repository):
+One solution is to correct the merge tracking information 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>When merging a feature branch, the best solution is to <a
+<p>Note that this should not be a problem with release branches (also
+called "maintenance branches"), because one typically does not merge
+them back to trunk. Instead, recommended practice is for new changes
+to enter on trunk and be ported outward to the branches that need the
+changes. When merging a feature branch, the best solution is to <a
 href="#mt-reintegrate" >use the <code>--reintegrate</code> option</a>;
 then this problem won't happen in the first place.</p>
 

---------------------------------------------------------------------
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 20:23:15 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.