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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 09, 2002 10:38 PM To: [EMAIL PROTECTED] Subject: Re: Any Real time examples of Branching, Please!!! "Datla, Raghav" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
