Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!motcsd!hpda!hpcupt1!hpirs!runyan
From: runyan@hpirs.HP.COM (Mark Runyan)
Newsgroups: comp.software-eng
Subject: Re: Re: Source Code Control
Message-ID: <9630007@hpirs.HP.COM>
Date: 28 Jun 89 18:09:42 GMT
References: <133@tirnan.UUCP>
Organization: HP GSY/USO/UKL Cupertino, CA, USA
Lines: 38

>/ cheung@unc.cs.unc.edu (Clement Cheung) /  5:15 pm  Jun 27, 1989 /
>But identifying a version by name is not powerful enough because it does
>not convey any information about that particular version. A lot of the
>research SCM systems identify a version by attributes values. These
>attributes describe the properties of that version of the program.
>This concept is already in DSEE. A version that matches the specified 
>attributes values is selected. In DSEE you can also have preferences
>for your selection. You lists the most desirable properties before 
>the less desirables properties. 

Obviously being able to define the properties of the revisions you are
interested in is a good (perhaps even great) idea.  DSEE would probably
solve most of the technical problems I have, except one... I don't have
an Apollo system.  

Note that the use of RCS symbolic names allows a person to maintain an
"slist" (mentioned in previous article) with the RCS file.  Unfortunately,
there isn't anyway to restrict when a symbolic name can be changed or who
can do, and the past status of a symbolic name in an RCS file is not kept
under any sort of history control.

My experience to date has been that RCS and SCCS are not sufficient for
complete software configuration management, especially on projects with
more than 10 engineers and more than 10,000 lines of code.  Usually a
front-end must be built that uses RCS or SCCS to do the version control.

There *are* systems such as NSE and DSEE, but I'm not sure how well they
do in an heterogeneous environment.  Personally, I favor DSEE (but then I
*do* work for HP :-).

Programs such as Aide-De-Camp or CMT (from Expertware) are "portable" (they
run on my systems anyway), but they seem to be such juggernauts that I
can't find the time to get a demo set up and see if they solve our technical
issues.  (Not only that, but as products that must be bought, the "need"
for these must be justified.)  Maybe these tools are the answer and I just
need to settle down and work with them...

Mark Runyan