Re: Any Real time examples of Branching, Please!!!

[Wim Kerkhoff]

Hi Pierre,

I've been keeping this post from you from two months ago in my Inbox for
quite some time. I've done some readings and digesting of various
material, and your method really does make sense for the size of your
team. I am considering suggesting this method at work with our new
releases.

In fact, I have taken the liberty of converting your post into a page on
Wiki site that I have set up on practical release branching with CVS,
over at:

http://www.nyetwork.org/wiki/CVSReleaseManagement

Wim

Pierre Asselin wrote on January 9, 2002:
> 
> "Datla, Raghav" <address@hidden> writes:
> 
> >     Can anyone post me examples of branching in real time
> >Dev-Stage-Production environment if you are using it. I will appreciate your
> >help.
> 
> Mine is not a real-time environment, but it is a real environment :-)
> In a nutshell, we promote to QA by tagging and starting a branch, and
> we promote to production by tagging on the QA branch.
> 
> Development is on the trunk.  When the product has the features we
> want, we tag the tip of the trunk for a QA-release and start hacking
> on newer features.
> 
> QA starts a QA-bugfix branch off development's QA-release and starts
> looking for bugs.  Bug fixes are commited to the QA-bugfix branch.
> When it looks good, we tag the tip of QA-bugfix for a Production-release
> but we keep fixing bugs on QA-bugfix.
> 
> Production exports the Production-release, builds it and runs it.
> 
> Bug reports from production are fixed on the QA-bugfix branch, a new
> Production-release is tagged, and production takes it.  I suppose we
> could start Production-bugfix branches off the Production-releases,
> but we don't.
> 
> After a while tHe QA-fixes branch is merged to the trunk, so
> Development has the bug fixes too.
> 
> Eventually, Development makes a new QA release.  A new QA-bugfix
> branch is started and the old one is abandoned.
> 
> The mechanics of this has some nitty gritty.  Read the manual at
> cvshome.org many times over.
> 
> -------
> 
> General rules:
>     1)  Always know why you created a branch, and stick to its
>         purpose.  Example:  no new features on QA-bugfix.
>     2)  Merge in one direction only.  Example:  from QA-bugfix to the
>         trunk, never from the trunk to QA-bugfix (no new features).
> 
> Some organizations prefer to develop on branches, for example one
> branch per feature.  When the feature is ready, merge with the trunk
> and abandon the branch.  Then the trunk is used for integration more
> than for development.  Releases to QA and Production can proceed as
> above.
> 
> --
> Pierre Asselin
> Westminster, Colorado
> 
> -----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
> http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
> -----==  Over 80,000 Newsgroups - 16 Different Servers! =-----
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs

Wim