Re: Managing multiple changes and branches

[Pierre Asselin]

In <address@hidden> address@hidden (Matt) writes:

>Our project has recently reached a maintenance
>phase, so we have a few people working on bug fixes and small
>enhancements and we have another couple of people working on one major
>enhancement.
>[ ... ]
>The answer may be to use the branch for the maintenance work,

That's how it's normally done.  Treat the milestone as a "release to QA",
requiring a tag.  Start a bugfix branch off the release point.  The
maintenance team works on that branch, the development team continues
its work on the trunk.

>From time to time, merge bug fixes from the maintenance branch to the
trunk;  plant a moving tag (cvs tag -F ...) at the tip of the branch
after every such merge, to keep track of what's already merged.


>but in order to not get enhancement code into
>regular production builds, we would have to maintain the single branch
>until the time when the enhancement is finished and they can be
>merged.

They're always merged.  The trunk (enhancement) has all the bugfixes
because you keep merging from branch to trunk.  When the enhancement
work is ready for QA, you repeat the process and start a second
branch.

You maintain the first branch for as long as you support the
un-enhanced version, for example if you ship to customers and sell
them support contracts.  You should merge further bug fixes to the
later maintenance branches and to the trunk.  Hopefully the fix
rate will start slowing down.  When you drop support, you just stop
working on the branch.