Re: [boost] Change to Release Procedure? (was: Another remindertomerge changes from the release branch)

From: Samuel Krempp (krempp_at_[hidden])
Date: 2002-12-03 10:26:34

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.

> My only major comment is that merging fixes from the main trunk into
> the RC may require more care if new development has also occurred in
> the file. I'd be inclined to say something like: "remember the version
> of the trunk file before you make the fix, then do a merge
> -j<prev-version> -jHEAD in the RC branch".

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

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 ? keeping
the branch synchronised can be a major relief for the author)
In fact, in this situation, you can 'remember the version', by putting
this tag '<branch>_next_merge_base' right before modifying the file. 

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>

(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.
(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)

-- 
Samuel