-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ziggy wrote: > Here is an example. Lets say the last release was LIVE-REL-2-3 > All the necessary modules that make up LIVE-REL-2-3 have been tagged with > the LIVE-REL-2-3 > > Now i am working on LIVE-REL-2-4 and make changes to 3 files. I check in > these 3 files and tag them with the label "BUG23" > > There might be developers who have checked in source files and tagged them > with "BUG22", "BUG44" etc which i do not want to include into LIVE-REL-2-4. > > LIVE-REL-2-4 should only include "BUG23" which i have just checked in. To > achieve this, i checkout LIVE-REL-2-3 and any files with the "BUG23" label > and build my application.
It sounds like you need a better handle on your release management strategy, and how CVS will fit into that. Remember that CVS is NOT a configuration management system, nor even a release management system. It is a version management tool, which fits into the overall release and configuration management strategy that you must devise. Basically, if you have two or more deliverables, which are going into two or more different releases, you MUST use branches. As you've discovered, not using a branch is complicating your life horrendously, and will likely bite you in the rear end when you least expect it. There are two common approaches you can take. The first approach, and probably by far the most common, is to use the mainline for all release development, and create branches for bug fixes. Generally, use this when your development time tends to be smaller than the release time, or releases are ad-hoc (e.g. we'll release this when the features are done). When you create a release, you create a branch then and there. Any bug fixes are put on the branch, then merged into the trunk when complete. The second approach is to create a branch for each release. No development is ever done on the trunk. This approach is useful when you have frequent releases (monthly or even more frequently) and you have some items in development which will take longer than one release cycle to implement. For example, I'm currently on contract to an organization that has monthly releases, and we have items scheduled to be delivered November, December, March and June, so we currently have four active development branches. When it's time to start working on a release, you merge a chosen branch (usually the most recent branch for the most recent release, but it doesn't have to be) to the trunk, then create a new branch for the release. As each release is released, you merge the code from that release's branch to the trunk, and to any subsequent branches (going back to my previous example, we'll have to merge November's changes into the trunk, and each of the branches for December, March and June). Each approach, of course, has its own advantages and limitations. I have omitted quite a few details here, to keep this email to a reasonable size :-) Your best bet would be to create a branch from LIVE-REL-2-3, then replicate your bug fix on that branch. Release 2.4 will be created from the branch. If your fixes for BUG23 should be included in 2.5 then you're done, otherwise you'll have to back out your changes from the trunk. - -- Jim Hyslop Dreampossible: Better software. Simply. http://www.dreampossible.ca Consulting * Mentoring * Training in C/C++ * OOD * SW Development & Practices * Version Management -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksIJKwACgkQLdDyDwyJw+O6yQCdHv2Si5YqyUmkWNdIVz5IWU3e YMUAnRWClIo8qcW/CVVE6Z8LOgiruC39 =MdPp -----END PGP SIGNATURE-----
