Xref: utzoo comp.unix.questions:14256 comp.software-eng:1621 Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!amdahl!johnm From: johnm@uts.amdahl.com (John Murray) Newsgroups: comp.unix.questions,comp.software-eng Subject: Re: Source Code Control Message-ID: Date: 13 Jun 89 17:42:21 GMT References: <132@tirnan.UUCP> <4750020@hpirs.HP.COM> <133@tirnan.UUCP> Followup-To: comp.software-eng Organization: Amdahl Corporation, Sunnyvale CA Lines: 41 In article <133@tirnan.UUCP>, john@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.)