info-cvs
[Top][All Lists]
Advanced

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

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


From: Datla, Raghav
Subject: RE: Any Real time examples of Branching, Please!!!
Date: Fri, 11 Jan 2002 15:16:21 -0500

Is there any way that we can set the restrictions or permissions on the tags
or release tags, for example we have a branch or tag which is created for
production, by mistake the developers might check out the files from the
production branch or tag and modify those files.
How can we restrict that type of incidents mainly for production tags or
branches?.

Thanks inadvance,
-Raghav



-----Original Message-----
From: address@hidden [mailto:address@hidden
Sent: Wednesday, January 09, 2002 10:38 PM
To: address@hidden
Subject: Re: Any Real time examples of Branching, Please!!!


"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



reply via email to

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