Using RCS for release management

[David Elliott]

In article <18261 at adm.BRL.MIL> Leisner.Henr at xerox.com (Marty) writes:
>	1) an automatic way of generating a release where a common ident string
>reflects the release level  (this isn't revision numbers of each source
>file) -- only one magic release string should be generated per delivered
>binary.

At MIPS, the compiler driver was modified so that during the link step,
the last file loaded was always named by the environment variable
RLS_ID_OBJECT.  Before starting the build for a release, an object file
was created containing two strings: one for RCS's ident command, and one
for SCCS's what command.  For example, the C source might be

	static char *RCSid = "$Header: UMIPS 3.10 mips$";
	static char *SCCSid = "@(#)UMIPS 3.10 mips";

A MIPS customer (starting with release 3.0) can use either what or
ident to see what release the binary came from.  An OEM can recompile
the commands with a different set of strings.  A source customer will
probably not use this feature.  The result is that MIPS's customer
support folks can figure out who made the binary when a bug gets
reported, and possibly find bugs created outside of MIPS instead of
wasting time reproducing a "non-bug".

>	2) What's the best way to extract the source code components of a release
>at a later date.  It seems we can extract by date, symbolic name (assuming
>one's assigned at release creation).

Symbolic revision names are your best bet, though can always ident
each source file at release time and build one big database of
file->revision number mappings and use that.

>	3) Do we want to use the first digit of the revision number to make each
>release?  This seems somewhat awkward, but will work to a limited extent.
>So release 1.0 will contain revisions 1.xx, release 2.0 will consist of
>versions at the 2.xx level, etc.  

This is up to you, and it's all a matter of taste.  You need to decide
whether your internal policies match your release policies.

Personally, I would rather work in an environment where nobody tells
me what revision control system to use, and doesn't design release
systems around the revision control system.  After all, if you have
to release source, there's a good possibility that your source customers
use a different system, and your data won't do them any good.

-- 
David Elliott		...!pyramid!boulder!stan!dce
"All he wanted was a Pepsi, but I wouldn't give it to him!" -- Mike's mom