Re: Procedural ways of using CVS.

[David Wood]

The approach centers around an enhanced version of the ant CVS Task that 
is used to create branches and conduct merges. It stores information about 
branches and tags in a database, and applies it to create the appropriate 
CVS commands. 

In practice this custom Task is used twice. The first time, it gets the 
destination branch into the working directory, tags the source branch 
(according to a uniform naming convention), and does the "update [-j 
previous-merge-tag] -j current-merge-tag". The output of that operation is 
watched by what has grown into a "slightly complex" parser whose job is to 
flag conflicts.

Then you'd do your build and any other tests you want to do.

The second use involves committing the merge and tagging the destination 
branch. 

address@hidden wrote on 10/17/2003 02:51:30 PM:

> 
> David,
> 
> Read through your procedure, was quite interesting. Can you tell some 
more
> details about ANT and CVS coordination with respect to tagging, merging
> etc.
> 
> 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
> 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
> 
> 
> 
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs
> 
> 
> 
> 
>