Xref: utzoo comp.software-eng:552 comp.unix.wizards:8415 comp.sys.att:3214 Path: utzoo!attcan!uunet!mcvax!ace!konijn From: konijn@ace.nl (Erik van Konijnenburg) Newsgroups: comp.software-eng,comp.unix.wizards,comp.sys.att Subject: Re: More SCCS usage/Has anybody heard of "SABLE"? Keywords: SABLE, SCCS, configuration management Message-ID: <503@ace.UUCP> Date: 12 May 88 01:34:22 GMT References: <647@vsi.UUCP> Sender: news@ace.UUCP Reply-To: konijn@ace.nl (Erik van Konijnenburg) Organization: ACE Associated Computer Experts bv, Amsterdam Lines: 68 Hi. In the recent summary of SCCS experiences, the following note touches on one of the most important parts of version control: keeping multiple files consistent. > Charles Lambert: > > ... Keep a System Description File that > lists all the version-numbered sources needed for a correct build. This > is simply a text document that has to be kept up to date. Since nobody > remembers to keep documents up to date, it is wise to have your shell > scripts do it automatically: every time someone deltas a file, the new > version number gets written into the SDF. And in article <647@vsi.UUCP>: > Stephen J. Friedl : > > [ Question about Sable ] > > Related to this, I have found that naked SCCS is really not > suitable for doing even small projects and would like to find > something more. I have tried to build tools on top of SCCS and > am getting closer, but "The Right Way" has eluded me. Who knows > of good configuration management software based on SCCS? Even > ideas would be helpful. > Using System Description Files is definitely the right direction for version control. If these files have a fixed format, they can become the basis of tools for practically all your source control. -- It is possible to create source distributions automatically. -- It is possible to produce a diff listing between two versions, not of a single file, but of a complete product, complete with the SCCS comments for all these changes. -- Since the version of the snapshot file is a complete identification of the product, it is sufficient to put the version of the snapshot file in a product. This means you no longer have to wade through pages of version strings to get the one you are interested in. -- By using SCCS simply as a "backend", much more flexibility is available. For instance recursion: one single version number identifies a complete distribution by giving the version numbers of component parts, which give the version numbers of component parts, and so on. -- The version identification of a System Description File is a great shorthand in communication between developers and distributors: ``Version 6.25 of the C compiler does loop invariant code moving, and could you do a trial UNIX distribution and validation with it?'' Generating the distribution is then a matter of passing that single version number to an extraction tool. We built a system based on System Description Files, and find it indispensable in keeping order in our distribution (several hundred megabytes of kernels, uitilities, compilers, etc.). There is a short paper on these version control tools and how they fit in with validation, distribution generation, and software problem report management. If you're interested in a copy, send mail to -- Erik van Konijnenburg +31 20 646416 konijn@ace.nl or ..!uunet!mcvax!ace!konijn