SCCS Summary
2007-12-25 7:16:00
Thanks again.
Doug Peterson
My message to the NET:
I am working on a large software management project, and SCCS has been chosen
as the management tool. The user community is a group of Nuclear Engineers
using FORTRAN with not a lot of UNIX background, and even less SCCS experience.
There are multiple (and LARGE) applications involved.
SCCS can become confusing, especially with multiple programmers on the same
piece of code, and if versions like 1.2.3.4 begin to show up.
I would like to hear about other similar projects which use this, and how
well it does(did) or doesn't(didn't) work. Please comment the scale of the
project, the people involved, and some general remarks about the
industry/application.
Also, is there a paper or other publication anywhere that addresses SCCS?
I'll summarize to the net.
Thanks.
Doug Peterson
PS - Does anyone know where I can get Allman's SCCS paper,
besides the 4.3BSD DOC?
From: Kennedy Lemke <Kennedy_J_Lemke@Princeton.EDU>
Bummer that they chose SCCS--I have worked in [smaller-than-yours]
environments that use both rcs and sccs, and I much prefer rcs for
its ease of use. But I don't want to even get into the rcs vs. sccs
issue, as I'm sure you don't either. Don't get discouraged, though;
there are plenty of folks who use and love SCCS, and it *is* a
reasonable system for revision control.
The only document I know of describing SCCS and how to use it is
Eric Allman's paper (from about 1986 or maybe even earlier). The
document is entitled "An Introduction to the Source Code Control
System" and comes with the BSD 4.3 manuals (and is probably available
from other sources).
From: guttman@mashie.ece.jhu.edu (Mike Guttman)
The best package I've ever used for this sort of thing was Apollo
Computer's DSEE (Domain Software Engineering Environment). They
thought of everything. I was the administrator and a member of a
ten-programmer project using this and any complaints I had were very
minor. However, this is not available on Sun computers and, hence, of
little use to you.
I do have some advice for you though: Forget SCCS! It's very clumsy
to use. It has about 1/8th of the capabilities that you would need
for a multi-programmer project. I don't know how much I should whine
about this, just forget it.
You might want to consider RCS (revision control system), available by
anonymous ftp from cs.purdue.edu. This is certainly better than SCCS
as far as useability and capability, but still has only about 1/2 of
what you would need/like.
Neither of these two are made for multiprogrammer projects. I've
heard about DRCS (Distributed RCS), which is a rewrite of RCS for
multiprogrammer projects, but I have no experience with it (I also
forgot where to get it).
Sun was supposed to come out with NSE (networked software environment)
as an answer to Apollo's DSEE. This is your best bet, but I don't
know if it is out yet or how well it works.
From: rfinch@water.ca.gov (Ralph Finch)
We have a similar problem, although perhaps not in the scale as
your situation. We decided to use RCS, and are implementing an
interface to it using GNU Emacs-lisp. This is designed to handle
multiple changes to the same file, and avoid having to deal with
branch numbers. It should be ready in a month or so.
From: raw%beta@LANL.GOV (Richard A. Wiley)
I tried to do this a couple of years ago, and ended up giving it up. SCCS
has some nice features, but I was fighting too much resistance from the
programmers who were doing the work. The administrative load was starting
to look pretty heavy too. This was for a computational fluid dynamics code,
about 100K lines of FORTRAN, and maintained by four people. The source also
included code for several different architectures (VAX, Sun, Cray, IBM, CDC).
I am now working with a Pressurized Water Reactor code, about 150K lines,
and maintained by about 8 people. This has always been maintained using the
Historian library maintenance tool from OpCode, Inc. This code, like the
other one, has a single source library which is used to generate sources
for several different systems (Cray, CDC, IBM).
It is being moved to UNICOS, so SCCS is
an option, but I don't think it will really support what we are doing,
especially since some of the code is common to more than one (but not all)
of the architectures.
Sun has a product, the Network Software Environment (NSE), that is a flavor
of SCCS designed for use by several people at the same time. It has better
administrative tools, and may even address the problem of maintaining source
for different architectures. But is costs about $6,000 for a single server
network license. But then Historian is probably a lot more than that.
Let me know what you find out.
From: brianc@daedalus.ucsf.EDU (Brian Colfer)
Why SCCS when RCS is really much better ... better logs, simpler
to work with, better many areas... if you need the ftp address where
you can get source for RCS for free let me know.
Return-Path: <KOHR@ll.mit.edu>
Have you looked at all the SCCS man pages (sccs(1), sccs-get(1),
etc.) and at Sun's separate document on SCCS in the "Programming
Utilities and Libraries" manual. The SCCS document is highly
tutorial in nature (the man pages obviously are not).
From: Bryan Rawson <rawson@ocean.washington.edu>
SCCS is best used when sources are 'administered' by library
personnel who specialize in SCCS. Left to a programming staff,
I'm sure that you'll see the project severely burdened by the
hassles of SCCS. It is also only capable of maintaining one
outstanding version of a module at a time. There is no facility
supporting simultaneous/multiple updates to the same module.
For the last few years I was working for a Litton division,
supporting code development on 4 VAX 8550 Ultrix systems with
about 150 engineers. Shortly after the project released its
second baseline (about 700k lines of CMS-2 source code) we took
a look at the source code control. The engineering staff had
implemented several utilities to front-end SCCS and manage their
updates. Beyond that absolute frustration that SCCS would not
handle multiple updates, there were also problems with 'diff'
(a major component in SCCS) breaking with large files, etc.
The programmers had begun doing diffs of diffs and many other
overhead functions, spending more of their time doing SCCS tasks
than debugging code.
After placing the ultimate control of the sources in the hands
of a Software Control Center, whos sole purpose was maintenance
of project baselines and customer releases, SCCS became useful.
This wasn't without a great deal of pain and several hours of
instruction and creation of front-end scripts to help out the
non-programming librarians.
The bottom line: 1) SCCS will not support multiple/simultaneous
updates (merger) to the same module; 2) Many versions of SCCS
break with large source modules (10k lines of code) due to problems
with base UNIX utilities; 3) SCCS requires lots of attention and
specialized skills.
Good Luck!
From: proton!baumann@ucrmath.ucr.edu (Michael Baumann)
We have used SCCS here with little or no trouble. We have a treatment control
system for our proton accelerator (~150K lines of C code) under SCCS. What
I did to make it easy is to have each user have a "mirror" of the
project directory, and write a number of scripts that
a) check files in/out of the project directory to the local directory
b) Find any new files in the project missing from the local and get them
c) update the mirrored file to the current rev.
Anything that affects the project sends mail to the group to notify them
of the change, local news is used to give a verbose description of the
changes.
We are, however, experienced UNIX hacks (with a couple of former sys-admins)
From: jaf@Inference.COM (Jose Fernandez)
I would be *very* interested in your summary. Here at Inference, I've come
to the conclusion that a PERSON has to act as coordinator. (After all, WHY
are two people editting the same file at the same time.)
From: abair@turbinia.sps.mot.com (Alan Bair)
You may also want to look at CVS. It is a set of tools that sit
on top of RCS (Another program that does what SCCS does), but is
targeted toward LARGE projects, worked on by MANY people. It handles
the problems of several people trying to work on the same code and
making sure everything is kept under control and properly updated.
I have used RCS/SCCS, but not actually used CVS. Another group in
my area has been using CVS and indicates it is a VERY handy tool.
If you want some more info, I think I can dig up a paper on RCS/CVS.
From: hall@hunter.crim.ca (Ron Hall)
Get RCS available at these fine anon ftp sites....
arthur.cs.purdue.edu 128.10.2.1
mimsy.umd.edu 128.8.128.8
From: montnaro@moose.crd.ge.com (Skip Montanaro)
In my experience, ID branching, which is what gives you long version numbers
like 1.2.3.4, is rare. I've used SCCS for years, and couldn't tell you how
to create a branch without looking at the man page for get(1).
You are aware that Sun supports the sccs(1) command, right? That improves
the sccs user interface substantially. I wrote an sccs shell script that
I use to front end the sccs command itself. A summary of the things it does:
* takes sccs delta commentary from properly formatted module headers in
the file,
* has a "last n" command that prints the recent delta commentary for all
modules modified in the last n days,
* has much faster "info", "check", and "tell" commands.
Another shell script I wrote called genbase, allows SCCS users to create
named project baselines. For some unknown reason, I didn't incorporate it
into the sccs shell script. (That's where it belongs.)
In common usage, SCCS isn't too bad. I imagine it's more difficult to use
in esoteric ways.
Comments
Got something to say?
You must be logged in to post a comment.
