Re: CVS Integration Branch Strategies

[Kaz Kylheku]

"Johnson, Susan" <address@hidden> wrote in message news:<address@hidden>...
> I have a question regarding the creation of new
> integration branches.
> 
> Our developers do all their work in the main trunk.
> 
> I do the official CM builds in an integration branch
> off the main trunk.
> 
> The developers check their changes into the main
> trunk and provide me with a list of their files and
> revisions, then I merge them into the integration
> branch. I then build on the integration branch and
> after it passes testing, apply a tag to the
> revisions on that branch.

This is a ``wrong way merge''. If things need to be fixed in the
official release, the responsible developers should switch to release
branch and fix it there. Then merge these patches from the branch back
to the trunk.

> Whenever we have new development (as opposed to
> bugfixes) then I want to create a new integration
> branch from the main trunk and obsolete the old
> integration branch.
> 
> My issue is in how to create the new integration
> branch from main.
> 
> I can't use HEAD in main as my starting point since 
> there may be code changes checked into the main trunk
> that aren't supposed to go into the install until a 
> future date. 

If the future work is done in the same stream as current work, then
quite simply your process does not allow you to do what you are trying
to do.

If you want to separate ``this release'' work from ``future release''
work, then you need two steams. A reasonable approach is to use the
main trunk for the future work, and a branch for the immediate work.

You start by making a development plan, which involves deciding
exactly what features and fixes are going to be developed for the next
release and which will be postponed. You create a branch for the
current plan, and have the developers execute the plan on that branch,
and only those things specified by the plan. In the meanwhile, some
other developers can do the riskier, more experimental future work on
the trunk. Merging down is done frequently, of course.

If the plan work is done cleanly enough, that plan branch can become
the current release branch; you don't need to nest another branch
within it for stabilizing.

> If this was ClearCase then I would create the new 
> branch off /main/0 and copy-merge the files over, 
> but I don't think that iss possible using CVS.

I don't see how merging wild and wooly changes from the main trunk to
your stable branch is going to help you, even if you do it selectively
(file by file).

If you use version control intelligently, you should never have to do
branching and merging on individual files, and never have to obtain
lists of files and revisions from developers.

Being able to merge from any branch to any branch is useful for
maintaining separate product lines that forever diverge. CVS's one way
merging is more than adequate for a release process.