[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What is the best way to checkout by tag

From: Ziggy
Subject: Re: What is the best way to checkout by tag
Date: Thu, 22 Jul 2010 17:29:17 +0100

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 <address@hidden>wrote:

> 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.
>                 Consulting * Mentoring * Training in
>    C/C++ * OOD * SW Development & Practices * Version Management
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla -
> YMUAnRWClIo8qcW/CVVE6Z8LOgiruC39
> =MdPp

reply via email to

[Prev in Thread] Current Thread [Next in Thread]