Re: Procedural ways of using CVS.

[David Wood]

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.  :)

address@hidden 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