Path: utzoo!attcan!uunet!mcvax!unido!tub!coma!andy
From: andy@coma.UUCP (Andreas Lampen)
Newsgroups: comp.software-eng
Subject: Re: Source Code Control
Message-ID: <412@coma.UUCP>
Date: 27 Jun 89 17:37:03 GMT
References: <791@redsox.bsw.com> <357@umigw.MIAMI.EDU> <793@redsox.bsw.com>
Organization: Technical University of Berlin, Germany (West)
Lines: 70

In article <793@redsox.bsw.com>, campbell@redsox.bsw.com (Larry Campbell) writes:
> There is one problem with the scheme I suggested, though, which I noticed
> only after I posted the original article.  Unfortunately, a revision can
> have only one state.
> 
> This is a problem because we believe strongly in code reuse.  We have
> several modules that are used by more than one product.  Ideally, we'd
> like to be able to say something like:
> 
> 	This is rev 2.4 of foo.c, and it belongs to:
> 		Product A version 1.05
> 		Product B version 2.06
> 		Product C version 1.34
> 
> I can't think of any good way (short of building an add-on wart) to do
> this in either RCS or SCCS.

Not true!
You can use RCS's mechanism of naming each revision with any number of
symbolic names.  By this you can attach to Revision 2.4 of foo.c
symbolic names like "Product_A-1.05", "Product_B-2.06", *and*
"Product_C-1.34". The problem is, that this information is not easy to
retrieve with genuine RCS commands (rlog is *very* verbose).

Generally, the main precondition for a proper release management is
the ability to store the "right information" at the "right time" in
the "right place" and to be able to retrieve this information in an
appropriate way.

I think you can do the things you want with SHAPE.  SHAPE's object
base (AFS) provides a mechanism to store any number of (freely named)
attributes, each of which can hold any number of values, with each
version.  So, although the SHAPE toolkit does not provide a proper
release management (yet), you can introduce a mechanism to keep track
of the history of your releases quite easily.

As an example you may look at the Shapefile for AFS in the SHAPE
distribution. There is a target
- release:
which is followed by a sequence of (sometimes cryptic) commands that 
- generate a new release number for AFS and a c-function returning
  this release number (to be bound into the system)
- generate a unique symbolic name for the new release
- publish all unpublished (== new) versions belonging to the new release
- and marks *each* component version belonging to the release
  with the generated symbolic name.

All these actions are done when typing the command "shape release".
Later on, with the command "vl -n Product_A-1.05" you can get an
overview of the names and version numbers of all component versions
belonging to Release 1.05 of Product_A in the current directory.

The question "Which Product versions does version 2.4 of foo.c belong to"
is a bit more complicated to answer. The command 

"vl -U __SymbolicName__ -ux foo.c\[2.4\]" leads to the output

- foo.c[1.0]: __SymbolicName__=Product_A-1.05
- Product_B-2.06
- Product_C-1.34

which might not be 100% the output you want. But with a small shell
script, a bit sed, a bit awk... even this can be managed with small
effort.

Andy

-- 
Andreas Lampen, TU Berlin
UUCP:   andy@coma (unido!coma!andy)
BITNET: andy@db0tui62