>>> 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