Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!zephyr!tektronix!reed!arnav!tirnan!john
From: john@tirnan.UUCP (John Richartz)
Newsgroups: comp.unix.questions
Subject: Source Code Control
Summary: Configuration Management
Keywords: SCCS, Source Control
Message-ID: <132@tirnan.UUCP>
Date: 31 May 89 05:08:18 GMT
References: <276@kurz-ai.UUCP>
Organization: C20, Inc., Aloha, OR
Lines: 45


    I'd like to second MacK's motion for a discussion of source code
    control strategies, facilities, or systems. I'm involved in
    implementing a source code control capability and have chosen to
    base the implementation on CCC from Softool (after considering
    extending SCCS, or using ADC from SMDC) and am not having very much
    luck finding realistic discussions of usable facilities. We're
    developing this in an environment of networked multiuser machines
    on which one will act as a source code repository with development
    occurring on the others.

    Clearly, the floppy (I guess this is a reference to PC based
    development) approach, or anything similar, is fraught with peril.
    But any approach based on ad-hoc procedures is likely to produce a
    product that is difficult or impossible to maintain - particularly
    when multiple product versions, products requiring site or
    installation specific differences, or derivative products must be
    managed.  While I'm reluctant to admit such a thing, even a PC can
    be used as a legitimate platform for some aspects of the
    development and provision must be made within a 'real'
    configuration control (note the change from "source control")
    system to accomodate this.

    I'm taking the approach that the 'developers' are responsible for
    provision of the source code and for changes to handle bug fixes
    and functional product extensions, while the configuration
    management people handle release builds, packaging, and releasing
    the product. (Developers are responsible for builds during their
    unit test activity, but use the same build procedures as
    employed for release builds.)

    Another consideration is to connect the configuration management
    system to the problem tracking system to allow us to readily
    track the progress of bug fixes through the resolution stage.
    This, of course, requires some discipline in generating change
    documentation - both to initiate a change to a product, and by
    the developer to identify what he did (or intended to do when
    operating on a source module).

    So, how 'bout it, guys? Like to discuss capabilities provided to
    developers? source control environments? configuration
    management issues??? In another newsgroup, perhaps?

    John Richartz
    !tektronix!reed!tirnan!john