Samuel Krempp <[EMAIL PROTECTED]> writes:
> Le lun 28/10/2002 à 04:19, David Abrahams a écrit :
>> Also, in this version of the command line instructions I dropped
>> > all the last_merge tagging instructions. This seems like lots of
>> > extra complexity without much purpose. But perhaps I'm missing
>> > something so please review and comment.
>
> If my guess is right, the role of the tag really was to serve as a base
> for the next merge.
> In trunk (old procedure style) :
> cvs up -j <branch>_last_merge -j <branch> <files>
>
> Without this tag, we have to remember what was the previous version of
> merging, and batch merges are not easily applied.
However, batch merges into a release candidate branch seem as though
they should be (very) rare.
> When all changes to trunk are propagated to the branch, this version to
> remember is merely the last version when we did a merge, and could be
> stored in a tag (strictly symmetrical to the <branch>_last_merge)
In fact, we could still call it that, though more-explicit
source->target naming might be helpful.
> In order to make sure I got the procedure right, let's consider the
> example of a simple library with an issue, that the author wants to fix.
> he tries his fixes and improvements in the trunk, and when satisfied
> (regressions show OK) merges the trunk into the branch.
>
> In this situation, keeping a tag of the last merge (but on the trunk
> side. so we need a new tag name, e.g. <branch>_next_merge_base)
Yick. But OK...
> makes everything smooth. You can even merge a whole directory in one
> line, once the regressions show you fixed the issue without causing
> new ones.
Sure, I guess. I'd prefer to manually review each change that goes
into the branch, since other development may happen in the trunk.
> I understand you were speaking of situations where some
> modifications were applied that should not go into the branch, and
> the version to remember would not necessarily be the one of the last
> merge. (BTW what kind of changes should an author restrict himself
> from merging into the branch, if it doesn't seem to break any
> regression ?
"Major, potentially destabilizing changes". It's a judgement call,
really.
> keeping the branch synchronised can be a major relief
> for the author)
What do you mean by "synchronized"?
> In fact, in this situation, you can 'remember the version', by
> putting this tag '<branch>_next_merge_base' right before modifying
> the file.
The person who initially creates the branch should also create the
merge tag at the same time.
> In both cases, the tag has the same use : it is intended so as to allow
> later
>
> cvs up -j <branch>_next_merge_base -j HEAD <files>
Sure.
> (thus it's more a predictive 'next_merge_base' tag than a 'last_merge'
> one in my opinion)
>
> All in all, I think in most cases a <branch>_next_merge_base tag
> will simplify the merging hasles imposed on the maintainer, and it
> should be added to the procedure docs.
It might. I think it will seldom be used, but I don't mind adding it
as long as developers also understand that especially in a RC branch,
all changes must be individually reviewed, even if they're created by
using an auto-merge. A false sense of security about using -j would be
dangerous.
> (A better name can be found, that's not my point here. but at least,
> calling it <branch>_next_merge_base corresponds quite precisely to
> its use)
True. However, I would prefer a standard tag format for
branch-to-branch synchronization labels, e.g.:
sync_<source-branch>_TO_<target-branch>
And, of course, a nice front-end script for cvs which automatically
creates these tags for us and automates the merge process ;-). Oh, and
of course, integration with Emacs <wink>.
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
