[H-GEN] RCS Usage

[Ben Fowler]

[ Humbug *General* list - semi-serious discussions about Humbug and     ]
[ Unix-related topics. Posts from non-subscribed addresses will vanish. ]

Hi Jason and all,

Please excuse the length of my post.

Jason Henry Parker wrote:
> So I'm finding that in order to be able to make and unmake changes as
> needed, I'm spending a few hours hacking (with an aim in mind), then
> creating a diff and selectively reapplying portions for separate
> checkin.  In theory this means that if I have to revert any change in
> functionality it should be easy (easi*er*, maybe) to do so.
> 
> I've also been rethinking RCS as a tool for development in small
> teams, and looking into various options (rcs -s, for example).  Do any
> of you have any stories or tips you'd like to share?

I'm unsure whether our experiences relate directly to what you're doing 
at the moment, but I'll share anyway :)  Your mention of "rcs -s" 
reminds me of a trick we use with release tagging in CVS to mark 
"baseline promotions", which I'll explain below.  I'm no CVS guru, but I 
figure that the rcs -s option is what CVS uses to implement tagging.

We use CVS (plus a couple of other neat tools like viewcvs and cvsgraph) 
at work.  I find that CVS is a better RCS than RCS :)

We have just started using CVS properly as part of our configuration 
management system and we find it a good fit.  We have several pieces of 
software which require a lot of developer effort and we've decided to 
implement an IEEE-like config management system (lots of policy plus a 
few tools).  We have the following requirements.  We need a thorough 
record of all changes made to the software.  We need a stable baseline 
from which to release from at all times.  We also need the ability to 
have multiple programmers independantly gut the source code being 
managed if they need to, without giving other people a hard time.

We've adopted a scheme where the trunk of the tree is always stable, and 
every time someone needs to fix a bug or three, or add a new piece of 
functionality, they file a 'config request' and a branch is created for 
them.  They can ask for any subsequent changes made to the stable trunk 
to be merged to their branch (config update request (CUR)), and they can 
request that their stuff gets merged back into the baseline, subject to 
tests passing, etc (closing the config request).

Each developer can create sub-branches and checkin, rollback, take 
diffs, selectively reapply changes etc on their own branches to their 
heart's content without trashing the rest of the tree.  Obviously, 
because of CVS' limitations, you need someone who knows what they're 
doing to be onhand to fix screwups and keep the system operating.

I particularly like CVS because of it's ability to tag sets of files, 
which comes in handy for baseline promotion.  Similar in concept to "rcs 
-s", we tag the trunk using standardised descriptive identifiers 
identifying the state of the baseline.  The trunk in CVS is always the 
"rock solid stable" part of the source tree, and its tag history should 
be a progression consisting of a number of merges from developers' 
working branches, plus tags for when it's "promoted", i.e. system tests 
have passed, releases have been cut, etc.  You can rename tags, and tag 
tags as well, which gives you the ability to promote a particular 
snapshot through a progression of milestones (system tests, integration 
tests, acceptance testing, release).

This system might seem a little complicated, but it appears to be 
achieving the goals we originally set out for it.  To ease the burder of 
administering this mess, I've been asked to write some web-based 
software to automate much of the process of accepting config requests, 
creating branches, closing CRs, etc etc - complete with Bugzilla [1] 
integration.  With luck, it'll be Open-Sourced, like much of the other
stuff we're building [2].

Anyway, I hope enough people find these comments interesting enough to 
justify the time I spent writing it.  Have fun.

-regards,

Ben.

[1]  Ask me sometime about the hassles I had choosing a suitable bug
      tracking system for our team at work.  I think that the fact there
      are so many defect/issue tracking systems out there
      points to the fact that few of them do most things well.  Bugzilla,
      despite it's warts, seems to work good enough for us.

[2]  http://titanium.dstc.edu.au/

-- 
Ben Fowler, email: <ben.fowler at humbug.org.au> pgp/gpg key id: FFDE6AF7
   vanity web page: <http://azure.humbug.org.au/~zuul/>

                       "Who now remembers the Armenians?" -- Adolf Hitler
                                    (see http://groong.usc.edu/fisk.html)


--
* This is list (humbug) general handled by majordomo at lists.humbug.org.au .
* Postings to this list are only accepted from subscribed addresses of
* lists 'general' or 'general-post'.  See http://www.humbug.org.au/