Re: What is the best way to checkout by tag

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