[Top][All Lists]

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

Re: Multi-tier development CVS plan

From: Pierre Asselin
Subject: Re: Multi-tier development CVS plan
Date: Wed, 21 Jul 2004 20:44:24 -0400
User-agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.2.19-7.0.1 (i586))

adp <address@hidden> wrote:
> Did you get a response on this? We are looking to move from a single CVS
> branch (MAIN) to either a two- or three-tiered system. Would be happy with
> hints.

> We are thinking of this:

> unstable -> stable -> release

The usual way to handle this on CVS is an unstable trunk with
stable+release branches.

         \                                \
          \----stable1-----|---------|     \
                          rel-1.1  rel-1.2  \

Every time your unstable trunk reaches a milestone, you cut a
stabilization branch.  On this branch you perform only cleanups and add
no new features.  Eventually you tag your stabilization branch and cut
a release, after which the branch becomes a bugfix branch.  Promoting
a new batch of changes from "unstable" to "stable" is done by starting
a new stable branch.

Not shown on the diagram is how the bugfixes from maintained release
branches would be merged to later releases and to the trunk, but
that's standard CVS fare.

You *might* make the original promotion model work in CVS with floating tags:
cvs tag -F -r1.6 STABLE toto.c  --oops no, cvs tag -F -r1.5 STABLE toto.c
etc.  You could then check out with the -rSTABLE flag to get an
official "stable" tree without the unstable riff-raff.  That said, I
don't understand the promotion model well enough to give you sound

To recap:

> unstable:
> This is where our current development goes.

The trunk, also the default.

> stable:
> This is where we merge our soon-to-be-released code so that QA can begin
> work.

You don't really "merge" in the CVS sense, instead you fork a branch
to isolate changes on it from the unstable trunk.

> release:
> This is where we merge from stable, tag an official code release, and then
> push the release.

You could branch the stable branch, but ususually it's easier to just
tag milestones on it.

reply via email to

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