[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Procedural ways of using CVS.
From: |
David Wood |
Subject: |
Re: Procedural ways of using CVS. |
Date: |
Tue, 21 Oct 2003 11:18:34 -0400 |
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
>
>
>
>
>