konijn@ace.nl (Erik van Konijnenburg) (05/12/88)
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 <cl@datlog.co.uk>: > > ... 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 <friedl@vsi.UUCP>: > > [ 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
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (05/14/88)
There is a technique I use for keeping things in line with SCCS. Perhaps
it's widely know and not used for some reason, but here it is.
Assume I'm at a production level, say 1.1, and am ready to make another
upgrade. First I pull an initial branch of all the files:
for n in s.*; do get -b $n; done
Now when I want to change something I do:
get -e -t s.whatever
which keeps things moving along the branch. When I delta I add comments
as always.
When I'm ready to update to the next production level (which in this
case will be 1.2) I just do:
for name in s.*
do
get -e -t -r1.1 $name
delta -y"Production version" $name
done
This will force all programs to have a version of 1.2, even if they
weren't changed.
I do the intermediate access with a script which does an extract if
there is no writable version, asks if I want to edit, asks if I want to
make, etc. Not elegant, but simple, easy to use, and reliable.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me