[Top][All Lists]

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

Re: Procedural ways of using CVS.

From: AdabalaP
Subject: Re: Procedural ways of using CVS.
Date: Fri, 17 Oct 2003 13:51:30 -0500


Read through your procedure, was quite interesting. Can you tell some more
details about ANT and CVS coordination with respect to tagging, merging

Thank you.

|         |           David Wood                          |
|         |           <address@hidden>          |
|         |           Sent by:                            |
|         |           info-cvs-bounces+adabalap=schneider.|
|         |           address@hidden                         |
|         |                                               |
|         |                                               |
|         |           10/17/2003 10:50 AM                 |
|         |                                               |
  |       To:       address@hidden                                              
  |       cc:                                                                   
  |       Fax to:                                                               
  |       Subject:  Re: Procedural ways of using CVS.                           

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

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
> I don't know the topic anymore but if you browse the archive you may
> some good descriptions, sometimes with links to more info.
> bye   Fabi

Info-cvs mailing list

reply via email to

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