There've been a few people post about the way their company has wrapped a unix or other outside 'change control tool'. I think these are interesting and I admire the "technicality" that goes into that approach. And I appreciate their sharing it, here. But it stimulates in me a rather wild and uncontrollable desire to express my differences in opinion and approach. It's different when I do it, because this is what I do -- and I have a product to sell. Thus:
AD WARNING: Following is a blatant PRC brag and sales pitch thinly disguised as a technical discussion of its approach. (But I will stick with the main technical differences ... unless you want more, then e.mail me!) PRC is a complete software configuration management tool -- including change control / version control -- developed in and for the U2 environment. Besides the obvious -- that it is a finished / supported product -- PRC differs in some basic ways from other "mainstream" approaches. * PRC is written in and for the U2 environment. * PRC is project-centric, as opposed to file-centric (or item-centric) meaning the versioning is not so much against a specific file (program) (although that detail is kept) but rather the collection of bits and pieces of whatever (program, subroutine, process, paragraph, dictionary, Voc entry, whatever) that comprise "the change". * Backward regress-able versions of all changed items are stored -- in their entirety. (And self-managed.) No delta records, to apply in order to 'rebuild' ... you can pull up an old copy and look at it. Or view it against the current version with changes highlighted. * There are tools and utilities so that the programmer -- not from a management perspective but from a head-down/ coders / convenience perspective -- WANTS and LIKES what PRC is doing. This is key, along with ... * Our #1 mission in the development of PRC was that there not be any 'extra' task or step that must be remembered or could be (accidentally or otherwise) forgotten. With PRC you just work as usual -- the software is checked out, reviewed against permissions, backed up and so forth AS YOU GO. No extra steps or checking required. * There are clearances and procedures that can be put into place to handle any "emergency" or "exception" without violating audit requirements. * PRC supports he whole SCM /SDLC process from the problem report, through management of the projects (in terms of assigning, scheduling, estimating, tracking progress), the change control piece, test management, deployment and provides a single repository for auditing and reporting. I'll stop now. Reluctantly. :) Susan Joslyn SJ+ Systems Associates, Inc. [EMAIL PROTECTED] PRC(r) Real software configuration management for U2. Message: 2 Date: Thu, 19 Feb 2004 09:53:22 -0000 From: "Brian Leach" <[EMAIL PROTECTED]> Subject: RE: version control software To: "'U2 Users Discussion List'" <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" Jeff, We use a two pronged attack - I don't think I can share it (sorry) but here is what it does - none of it should be too difficult to emulate: First we have some BASIC routines that stamp our programs with a string in the format: ADGVERDATA='Version=xxxxxxxxx;' ADGVERDATA:= 'VerDate=xxxxxx;' ADGVERDATA:='VerHist=xxxxxx' etc. The format of the string means that we can search both source and object code for version stamps (being a variable assignment not a comment they get compiled into the object code string table). We have some simple subroutines that return this version information which we can use e.g. from I-Descriptors to list the versions and from setup routines to check versions; and we have wrappers around our installation routines and checks in the routine we use for any global cataloging to ensure that we don't accidentally catalog an older routine over a newer version. Secondly, we use RCS for delta-ing (we could use CVS but RCS was a simpler option for interfacing). To allow it to handle non-source items (eg dictionaries and parameter records) we wrapper the RCS routines (ci and co) through some routines that essentially maintain an index of the UniVerse location (ACCOUNT DICT FILE LEVEL ITEM) to a numbered UNIX file. These allow allow us to things like accept select lists, so the whole thing is command line driven and very flexible. The routines maintain an index between our version stamps (which are 3 level major.minor.build) and the RCS version (which is 2 level major.minor) so we can search on either. We also apply tags in the index rather than using RCS tags, which are a bit flaky. The routines use the index to copy the item to a type 19 file using sequentially assigned IDs, then commit the copy to RCS. The same index is used to retrieve the item again, and optionally copy the item back to its original location OR to a new location (another reason for using the index). As most of our applications are client/server or Web based, we then apply CVS to our whole development environment, including the RCS repository. Hope this helps, Brian Leach -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
