Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!deimos.cis.ksu.edu!uxc!uxc.cso.uiuc.edu!m.cs.uiuc.edu!render From: render@m.cs.uiuc.edu Newsgroups: comp.software-eng Subject: Re: Source Code Control Message-ID: <39400023@m.cs.uiuc.edu> Date: 13 Jun 89 01:00:00 GMT References: <133@tirnan.UUCP> Lines: 67 Nf-ID: #R:tirnan.UUCP:133:m.cs.uiuc.edu:39400023:000:3778 Nf-From: m.cs.uiuc.edu!render Jun 12 20:00:00 1989 Written 11:36 am Jun 10, 1989 by john@tirnan.UUCP: > 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. I'm curious as to what you consider "configuration specifics." By this do you mean such machine-dependent characteristics as word-size and byte-ordering or do you have a higher level notion? I ask because I'm one of the people doing research into software configuration management and I'm interested in what other people see as shortcomings of the SCM and version control systems they have used. If you haven't seen it, you might wish to take a look at the Shape system being distributed to the public in comp.sources.unix. It is an example of the current trend in UNIX-based SCM systems and represents some considerable advances over SCCS and RCS. It seems to do things that you sound like you need. > "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. As you mention, SCCS and RCS fall short when you need to do SCM for larger projects. There are several recent systems which attempt to address this problem. You might wish to take a look at the proceedings from last year's IEEE workshop on software version control for examples. Also take a look at the last proceedings of the SIGSOFT/SIGPLAN Symposium on Practical Software Development Environments. They talk about 3 or 4 systems (Shape is among them) which do some of the things you seem to want. For more background, there was a bibliography on the subject in SIGSOFT Software Engineering Notes 11:3 (July 1986). It's pretty complete up to the time it was published and lists 76 articles. > So - comp.software-eng? A glib response would be "So - what?" I don't really know what you want to talk about. If you want suggestions for solutions to your problems, take a look at the proceedings I mentioned. I can also re-post a list of vendors of SCM systems that someone posted a month or two ago. If you want to discuss the issues involved in SCM, I'd be happy to, though I have to have someplace to start. Possible topics include database support for SCM, distributed SCM, formal models of SCM, language-based support of SCM, object-oriented SCM, improving the efficiency of SCM systems, SCM in programming-in-the-large, and integrating SCM into a development methodology. Anybody want to throw out the first ball? > john richartz > !tektronix.tek.com!reed!tirnan!john Hal Render render@cs.uiuc.edu