"NeoAlchemy" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >I am not sure if this is the totally right place for the question, so > please redirect me if so. > > I am using CVS at work. The way it is being used bothers me. We > create a branch 'a' for development. If a new release is needed to be > made we make a branch 'b'. If we are still having changes go on for > branch 'a' we post the changes to branch 'a' and branch 'b'. The > cycle continues where we make make another branch, branch 'c' for > development off of branch 'b'. This doesn't seem like a responsible > way to use CVS. No one else on the team knows any better. What would > be the appropriate way to handle a sequential release cycle? >
Business requirements usually dictate how CVS is used. My personal prefence is to have normal, on-going development occur on the main trunk. This includes new features, enhancement, etc., and then I create a branch when it is time for a release. Some people suggest branching before the release, and others suggest waiting until afterward. The difference between the two depends on whether or not new development should be allowed to continue while a release is pending. Personally, I usually wait to branch until the release happens, or just shortly before (to allow time for fixes). So, for example, let's say you are working on a product, adding new features, enhancements, etc. This work would occur on the main trunk. Then your company annouces that all the work you've been doing is going to be released soon. You can: A) Freeze all *new* development on the main trunk and only allow feature completion and bug fixes to occur until the release happens, at which time you create a branch. At that point, new development can resume on the main trunk. If bugs are detected on the release, you can apply fixes to the branch and rebuild the branch code to get a new release. Then merge those fixes into the main trunk so that the next time you branch, the fixes will already be there. B) Branch immediately. In this case, new development (any new features and enhancements) can continue on the main trunk immediately. For some businesses, this may be essential, as they may have separate teams for future development and current (or pending) releases, and wouldn't want to stop future development while a release is being finished up. Work on the branch is then limited to the completion of features that were already scheduled for that release, unless otherwise approved (by someone like a project manager). When the release happens, merge everything from the branch back into the main trunk. There are probably lots of other ways to handle branching, but I think these two are the most common. - Dennis
