Sounds like your using CVS/Subversion VCS. The way your company operates is one way to do it. Depends if you are working on a release or a bug fix.
Usually development code is the trunk (working towards a release). A tag is then created and classed as a release. There is no need to create a branch unless an emergency fix is required, just gets messy otherwise. Depends how confident your are in your VCS to merge the files correctly (and binary files can not be merged).
Originally posted by Turbografx: Usually development code is the trunk (working towards a release). A tag is then created and classed as a release. There is no need to create a branch unless an emergency fix is required, just gets messy otherwise. Depends how confident your are in your VCS to merge the files correctly (and binary files can not be merged).
<font size="2" face="Verdana, Arial, Helvetica">I've never seen the "soon-to-be-released" code stay in the trunk. Generally, the more concurrent projects you are working on, with (hopefully) staggared release dates, the more of a need to branch code in the final stages of release.
This way any changes that happen in the branch can be tightly controlled without hampering the rest of the development team(s) in continued development on other products.
Yes, that usually means that the changes in the branch must also be merged into the trunk, but that is much better than a wholesale change made for project z killing your release of project x. [img]images/icons/smile.gif[/img]
And yes, testing must occur in both the branch and the trunk, but in most of the places I've worked in the test teams differed by project so it was not bad.
The only guy with the headache was the build engineer. (Who more times than not was me.)
We are typically testing and releasing on branched code while development continues on the trunk. When the branch release is done, the branch is merged back into the trunk and a trunk release is then done usually within 4-6 weeks. The typical life-span of the branch release is 5-7 weeks, during which time we enter duplicate items (branch and trunk) and perform duplicate development and testing.
Yes this is normal practice. We even have branching of defect reports implemented in our problem tracking system to support verification of changes done in both code streams (but not spoil statistics at the same time).
Dan, this really depends on how many developers are working on concureent releases. If work on the next release does not begin till the current release is finished, then there really is no need for a branch.
This is a good book to introduce version control and the open source VCS Subversion :