There was a similar thread about Build Processes (Release Engineering) in CVS back in August, started by Bil Joga. My reply outlines our tagging and branching model:
http://mail.gnu.org/pipermail/info-cvs/2001-August/018972.html If you look around that date you will see a few other replies. Also a helpful resource in this area is the Acme web site: http://www.enteract.com/~bradapp/acme/ Although Fogel's book covers some Release Engineering issues - I think there is need for a book to be written specifically about Release Engineering with CVS. Certainly I have spent many hours eeking out rare information about branching (restricting access to branches) & commitinfo scripts, and figuring out how to work around bugs in the log command to get valid change report information. I also know a fellow engineer that has successfully implemented CVSzilla, and the implementation details of CVS/Bugzilla integration would make an important segment of any Release Engineering discussion. I don't know how informative "Practical Software Configuration Management: The Latenight Developer's Handbook by Tim Mikkelson & Suzanne Pherigo " regarding Release Engineering in CVS, but if not, then I might summon the energy to start a "Release Engineering in CVS" book.... Do others know if there has been anything comprehensive published on the web or in book form about Release Engineering with CVS? Thanks, Teala -----Original Message----- From: Wim Kerkhoff [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 08, 2002 2:49 PM To: [EMAIL PROTECTED] Cc: Datla, Raghav Subject: Re: Any Real time examples of Branching, Please!!! "Datla, Raghav" wrote: > > Hi, > Can anyone post me examples of branching in real time > Dev-Stage-Production environment if you are using it. I will appreciate your > help. I'm interested in this well. We've recently moved to CVS, and I'm working on massively re-writing all our build scripts to support this. We use a scheme similiar to your Dev-Stage-Production environment. How do you plan to handle versioning? On the old system we used a 4 digit build number for each distributed file as well as each distribution. Ie, periodically make a release (e.g. Build 3200), but regularly we release new versions of files via an update system within the product. So, if they do an update today a new foo.jar might get pulled in with a build number of 2783, or a new docs.pdf with a build number of 1087. This has come to mean nothing, especially as a component gets moved up from Dev to Stage, it takes over the build number of the previous build number in Stage plus 1. We've got Dev in CVS, but have not done any branching yet for Stage and Production. In addition the branching, I want to figure out a better way of versioning. And this all should be powerful and simple enough to implement, use, maintain, and show our developers and techs how to use it... Your post comes at a good time, as I was about to do more research into how other projects handle branching, and what kind of examples the cvs books have. -- Regards, Wim Kerkhoff, Software Engineer Merilus, Inc. -|- http://www.merilus.com Email: [EMAIL PROTECTED] _______________________________________________ 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
