Xref: utzoo comp.unix.questions:14219 comp.software-eng:1619
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!zephyr!tektronix!reed!arnav!tirnan!john
From: john@tirnan.UUCP (John Richartz)
Newsgroups: comp.unix.questions,comp.software-eng
Subject: Re: Source Code Control
Summary: Source/Configuration Control discussion in comp.software-eng?
Message-ID: <133@tirnan.UUCP>
Date: 10 Jun 89 16:36:41 GMT
References: <132@tirnan.UUCP> <4750020@hpirs.HP.COM>
Organization: C20, Inc., Aloha, OR
Lines: 39


    Thanks to Mark Runyan (runyan@hpirs.HP.COM) and Mark Valentine
    (mark@spider.co.uk) for responding to my suggestion for discussion
    of these issues.

    It strikes me that comp.software-eng might be an appropriate place
    for discussion, since it seems to be fairly low volume now, and
    they're currently pretty hung up on whether software engineering
    really exists and whether you're better off training an Engineer
    to develop software than to teach a Software guy engineering.

    Mr. Valentine does, I believe, characterize the situation fairly
    well.  I've worked with several (mostly ad-hoc) variants of
    development based on either SCCS or RCS and find that the structure
    is generally not in place to provide a development model that
    allows for realistic development of a Product and any variants and
    descendents of it (admittedly this often results from lack of
    organizational focus on the problems). I believe that this is due
    to an inherent weakness in the model of a product as the state of a
    particular set of source files, rather than as the collection of
    source files and configuration specifics that define a particular
    instance of the product.

    "Source Control" is only a part of the problem and one can feel
    fairly comfortable knowing that the developers have retained a file
    revision history for each file, and one can certainly snapshot the
    development at product release by treating the product as the list
    of files in the source control system at some revision (the
    software bill of materials kind of approach, useful with both SCCS
    and RCS). But this gets really messy when you've got either
    multiple similar products, or perhaps site specific versions. So we
    immediately find ourselves considering a higher level abstraction of
    the product - and ending up with "Configuration Control/Management"
    rather than just source archiving.

    So - comp.software-eng?

    john richartz
    !tektronix.tek.com!reed!tirnan!john