I'll share what I've developed; it may be helpful to you and helpful to me as well, if anyone has comments. Keep in mind that every situation may require a different approach to CVS, and ours is _not_ the most common usage pattern (the most common, I think, focuses on systems or application software development, and that does get some anecdotal treatment in the manual). In my case the job is managing ongoing development of a running Java web application. There are a number of parties who work on various aspects of it in parallel, some off-site. There are generally changes being developed, tested, and ready for deployment simultaneously at a given time.
We maintain staging and production branches. The current production branch matches exactly what is deployed at all times. The staging branch is the same, except that it receives new code for testing before it goes to production. Projects happen on "Project branches" that fork from production when they begin, and merge to staging and then production for testing and deployment. A project may be continuous, or short-lived. If it lives a long time, other changes from the production branch since the fork may be subsequently merged into it. People may share a project, or they may use it alone. We use custom Java code, primarily in several custom ant tasks, to manage merges and the associated tagging automatically, and to integrate this process seamlessly with other aspects of our build and delpoyment process. With one ant task, we can merge, build, and commit that merge if there are no compile errors or conflicts (which we force users to resolve in advance), and then actually push changes to staging and production. It's easy to maintain good logging this way (ant's record task), another bonus. I'm quite pleased with ant's CVS support, and with ant in general. The assumptions in this approach work well for us because our application is fairly compartmentalized. In our case it's important not just to be able to separate out changes by user or project, but to be able to easily put them in (or take them out) of production without affecting other work going on in parallel. Most of all, it's important for us to not have a mystery about what should go in and what shouldn't when it's time to make a new production build (which may happen very frequently), although certainly not every 30 minutes. :) [EMAIL PROTECTED] wrote on 10/17/2003 02:22:53 AM: > > >I'm interested in how people organise their in-house projects from > an administrative point of view with CVS, for example, when they use > branching, tagging and how (or if) they use CVS with ant, anthill > and how they manage frequent builds and releases (ie, every 30 minutes) > > > >There is a brief amount of information in the cvs book (Open source > dev with CVS), but I'm looking for websites or peoples own opinons > on how they structure their in house development with CVS. > > There have already been questions (and answers) like this in the mailing list. > I don't know the topic anymore but if you browse the archive you may find > some good descriptions, sometimes with links to more info. > > bye Fabi _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs