Source Code Control

John Murray johnm at uts.amdahl.com
Wed Jun 14 03:42:21 AEST 1989


In article <133 at tirnan.UUCP>, john at tirnan.UUCP (John Richartz) writes:
> 
>     [... Having used] either SCCS or RCS[, I] 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).  . . .
>             [...Things get] really messy when you've got either
>     multiple similar products, or perhaps site specific versions.

A development group frequently suffers from tunnel vision,
to the extent that it cannot see how it fits into the entire
organization. This seems to be a real problem where both
hardware and software are being developed simultaneously,
or more particularly, when existing software is being modified
to run with new hardware. I like to think of this activity
as software "maintenance" rather than "new design". However,
organizations prefer to act as if they were designing from
scratch, even though they subsequently find themselves porting
software fixes forward from earlier versions, and so on.

Here's an interesting logistics problem. The prototype hardware
has a bug which will take several weeks to fix. A temporary fix
is applied to software to get around the problem and allow alpha
testing to continue. Software development is still continuing
at the same time. When the hardware problem is resolved, how do
you back off the temporary fix in an orderly fashion? (This is
basically an instance of the site-specific problem, I suppose).
Even establishing an appropriate mechanism for tracking the
changes can be a paperwork nightmare.

At Amdahl, one system we use tracks problem fixes and new s/w
enhancements simultaneously, and no source changes are allowed
without a corresponding entry in the tracking database. (See
Software Engineering Notes, ACM, Oct 1988 for my paper on it.)
Merging such software control with the corresponding hardware
change control system seems difficult, however; I'd be very
interested in hearing opinions on this subject.

- John Murray, Amdahl Corp, Sunnyvale, Ca.
  (My own opinions, etc.)



More information about the Comp.unix.questions mailing list