Re: What is the best way to checkout by tag

[Jim Hyslop]

-----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-----