You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Karl Fogel <kf...@red-bean.com> on 2008/06/02 21:03:23 UTC
Re: [PATCH] Release Notes: Information on the "natural history" currently present in svn:mergeinfo
Marc Strapetz <ma...@syntevo.com> writes:
> As discussed in
> http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=139270
> the attached patch for the Release Notes explains the presence of the
> "natural history" in the mergeinfo, impact on svn log -g and the
> resolution for a simple example. Hopefully I got the point and it's
> actually understandable ...
Committed in r31558 with various tweaks (mention the --reintegrate
option, etc). Thanks, Marc!
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Release Notes: Information on the "natural history" currently
present in svn:mergeinfo
Posted by Marc Strapetz <ma...@syntevo.com>.
>>> 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 <ma...@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@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
Re: [PATCH] Release Notes: Information on the "natural history" currently present in svn:mergeinfo
Posted by Karl Fogel <kf...@red-bean.com>.
Marc Strapetz <ma...@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Release Notes: Information on the "natural history" currently
present in svn:mergeinfo
Posted by Marc Strapetz <ma...@syntevo.com>.
> 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 <ma...@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@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
Re: [PATCH] Release Notes: Information on the "natural history" currently present in svn:mergeinfo
Posted by Karl Fogel <kf...@red-bean.com>.
Marc Strapetz <ma...@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Release Notes: Information on the "natural history" currently
present in svn:mergeinfo
Posted by Marc Strapetz <ma...@syntevo.com>.
> Wait -- I think you're right, and I misdocumented it a bit in the
> release notes just now. It *is* for feature branches, not for release
> branches (well, release branches shouldn't get merged back to trunk
> anyway).
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.
As far as I understand now, for "release branches" (in the Subversion
notion), there is no problem as trunk is merged to branch. For feature
branches, there is also no problem, because here --reintegrate is used.
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?
--
Best regards,
Marc Strapetz
_____________
SyntEvo GmbH
www.syntevo.com
Karl Fogel wrote:
> Marc Strapetz <ma...@syntevo.com> writes:
>> I was not aware that --reintegrate is the recommended way to
>> continuously merge back changes from a *release* branch; instead I
>> thought it would only be useful for *feature* branches.
>>
>> So in my opinion it would be helpful to have most parts of Mark
>> Phippard's reply also part of the SVN book. Furthermore, it might be
>> helpful to have a short overview on feature branches vs. release
>> branches and when to use --reintegrate resp. "normal" merge here.
>
> Wait -- I think you're right, and I misdocumented it a bit in the
> release notes just now. It *is* for feature branches, not for release
> branches (well, release branches shouldn't get merged back to trunk
> anyway).
>
> Is this your understanding too?
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Release Notes: Information on the "natural history" currently present in svn:mergeinfo
Posted by Karl Fogel <kf...@red-bean.com>.
Marc Strapetz <ma...@syntevo.com> writes:
> I was not aware that --reintegrate is the recommended way to
> continuously merge back changes from a *release* branch; instead I
> thought it would only be useful for *feature* branches.
>
> So in my opinion it would be helpful to have most parts of Mark
> Phippard's reply also part of the SVN book. Furthermore, it might be
> helpful to have a short overview on feature branches vs. release
> branches and when to use --reintegrate resp. "normal" merge here.
Wait -- I think you're right, and I misdocumented it a bit in the
release notes just now. It *is* for feature branches, not for release
branches (well, release branches shouldn't get merged back to trunk
anyway).
Is this your understanding too?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Release Notes: Information on the "natural history" currently
present in svn:mergeinfo
Posted by Marc Strapetz <ma...@syntevo.com>.
> Committed in r31558 with various tweaks (mention the --reintegrate
> option, etc).
It seems that I understand just by now the meaning of the
"--reintegrate" option and after reading Mark Phippard's replies around:
http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=78113
Regarding --reintegrate, currently the SVN book says: "And in fact it
does this by comparing the latest trunk tree with the latest branch
tree: the resulting difference is exactly your branch changes!", meaning
to me:
svn merge url://trunk@HEAD url://branch
instead of
svn merge url://trunk@LAST-REV url://branch
I was not aware that --reintegrate is the recommended way to
continuously merge back changes from a *release* branch; instead I
thought it would only be useful for *feature* branches.
So in my opinion it would be helpful to have most parts of Mark
Phippard's reply also part of the SVN book. Furthermore, it might be
helpful to have a short overview on feature branches vs. release
branches and when to use --reintegrate resp. "normal" merge here.
--
Best regards,
Marc Strapetz
_____________
SyntEvo GmbH
www.syntevo.com
Karl Fogel wrote:
> Marc Strapetz <ma...@syntevo.com> writes:
>> As discussed in
>> http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=139270
>> the attached patch for the Release Notes explains the presence of the
>> "natural history" in the mergeinfo, impact on svn log -g and the
>> resolution for a simple example. Hopefully I got the point and it's
>> actually understandable ...
>
> Committed in r31558 with various tweaks (mention the --reintegrate
> option, etc). Thanks, Marc!
>
> -Karl
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org