[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Managing multiple changes and branches

From: Pierre Asselin
Subject: Re: Managing multiple changes and branches
Date: 15 Apr 2002 22:46:02 -0400

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
>[ ... ]
>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

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]