Thanks Jim for the information. The problem i have is i cant support branching. I would like to but i am struggling to convince my boss to authorise as he believes it will complicate things.
On Sat, Nov 21, 2009 at 5:34 PM, Jim Hyslop <[email protected]>wrote: > -----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----- >
