http://invisible-island.net/ded/
Copyright © 2011-2020,2022 by Thomas E. Dickey
These are utilities which both simplify and extend SCCS.
I started these programs in March 1986 as scripts, and shortly after rewrote them as C programs.
My original motivation for writing these programs was to help rein in a "consultant" (more aptly "hacker") who was working with me. In addition to getting potato chip crumbs in the keyboards, he had no configuration controls aside from a monthly tape backup. To save disk space, he hardlinked development files into the release area. That cost us some time when he overwrote some of those files and lost their content.
At that time, my experience with revision control was limited. In a previous project, we had a CM group. It seems in retrospect that they did not use software tools, but instead relied on processes (people). In the 1986 project, a solution using people would not work.
This project used SVr2 minicomputers (NCR towers belonging to the project, as well as vendor-loaned Altos, Charles River Data Systems and Plexus machines). SVr2 had SCCS (which I had not used before). From its description, that could be used to alleviate our problems with source control. In response to my suggestion that we use SCCS, the consultant replied
No, things are too volatile right now. Wait.
Given the lost time (a few weeks), it was already too late. I discussed the problem with the project manager, and proposed using SCCS to capture a stable version of the sources. Reading the documentation, I saw that SCCS could be told to put its archives in a subdirectory, i.e., "SCCS". I surmised that the consultant would not notice those directories or be concerned about their contents.
I first wrote shell scripts to use the SCCS utilities to create archives. SCCS is clumsy; my shell scripts simplified this:
admin,delta andget.Conceptually of course, this is similar to the BSD sccs front-end. I encountered that a few years later. But there are additional features which are provided by my wrapper programs that are not in either BSD or AT&T SCCS.
When I wrote my scripts, I quickly realized that there was a basic problem with them: they would not be unobtrusive:
Therefore, retrieving a file (to repair damage done by the consultant) would be noticeable when looking for recently changed files.
I solved this problem by writing better tools. The improved
tool manipulated the delta program to make it store
the file's modification time rather than the current date. It
also retrieved files, setting their modification time to match
the date recorded in the archive file.
Being a typical hacker, the consultant never noticed the SCCS archives. I collected all of the source files into SCCS archives.
Later (after the consultant was gone), I collated the tape backups and built a source archive to use for researching changes that were made to the project over its three-year lifetime. Recording correct timestamps was essential to understanding the change history.
Utimately, these tools were made obsolete when I started work on RCS-based tools, called cm_tools in May 1988.
However, I continued to improve these tools, adding the
sccsput and sccsget programs (again,
initially as scripts), and the fixsccs utility. Like
the RCS-based tools, I made changes to allow the SCCS wrappers to
work as setuid-programs (to support a shared archive), though
these were less robust in that area).
Part of the reason for the prolonged use of this package was that I extended it for use in a later project which used a COTS product named "CmVision".
When I came into that project, they had no tool. They did have
a resident hacker, who had some shell scripts using SCCS. Those
were undocumented, and relied on the source archive being
world-writable. He did not know how to use sed (and
spent three days removing the word "beta" from the SCCS keyword
lines in about 1200 files).
Rather than prolong that problem, the newer management had tasked one of the engineers with evaluating suitable products. ClearCase was out — too expensive. They had just decided on CmVision when I arrived.
CmVision was then marketed by ExpertWare—it has been defunct by either name since late 2002. (As of 2014, web searches find several unrelated companies named "ExpertWare", and in fact other programs named "CmVision").
A poor tool is worse than none at all. I asked to see what CmVision could do, and found that the evaluation had been essentially based on cost and advertising literature. Further, I found that CmVision was marketed as a front-end to RCS or SCCS. It went beyond the capabilities of either (by making directories, as well as files, controlled objects). I investigated and found that its support for RCS did not work. The SCCS support did work.
CmVision had a Motif GUI and an interface which ran in a terminal. Neither was useful:
cmv, the GUI, showed a graph of all files in
the system. Perhaps usable for 50-100 files, it was unusable
with our project of 3500 files on a heavily loaded Sun
workstation.cmt, the terminal interface, was a full-screen
maze of menus with no online help, no useful error messages.
Only one person (of 50-60 people) on the project mastered it.
Not me.Of course part of my interest stemming from the choice between RCS and SCCS was that I had written tools for those.
I wrote a new program which would map filenames between a
developer's work area and the CmVision archive. With that, I was
able to write scripts that used putdelta and
getdelta for working with CmVision. Likewise, I
cloned and extended the support in ded for viewing archive information for
CmVision.
That made a usable interface for CmVision and (except for the
one user of cmt) we used my tools as its front-end
for several years. By then, we had migrated to PVCS (again with
my tool extensions), and dropped maintenance on CmVision. At that
point I reconstructed the legacy CmVision archives as ordinary
SCCS archives (since our use of PVCS on Windows did not address
the need of development).
Download both files (you'll need the library):
The Open Group documents the command-line utilities for SCCS, but (as of 2020) does not document the file-format:
The file format itself was documented in sccsfile(5), but is intentionally left unspecified by the above cited.
The Open Group also has documentation for the sccs front-end program.
CSRG cdrom #4 holds a directory-tree of SCCS-files, including a copy of a source for SCCS. A README at the top of the tree states:
This disk contains a snapshot of the /usr/src tree as it existed
on June 23, 1995, approximately one hour after the final 4.4BSD-Lite
Release 2 distribution from the Computer Systems Research group
was cut. The project began using a source code control system (SCCS)
in 1980 (three years after Bill Joy began his initial Berkeley UNIX
development). Initially only the kernel was put under SCCS, but
by 1983 everything had been put under SCCS. The source code for
SCCS commands can be found in local/sccscmds. Once built they can
be used to review the SCCS logs.
The list of contributors to the Berkeley Software Distribution
(BSD) runs to hundreds of names. For a complete list, see Contrib.
Three other disks are included in this series; two disks with the
various BSD distributions and one disk with historic AT&T and other
distributions. Please note that all four disks contain AT&T
proprietary (both copyright and trade secret) files. Therefore,
these disks may not be redistributed without permission or license
from AT&T or its successors.
Marshall Kirk McKusick
Keith Bostic
The initial kernel source check-ins were done April 9, 1980 (105 files).
The next set of check-ins was done May 10, 1980 for Eric Allman's sccs front-end, followed by the “me” macros for nroff, the manual page for sccs, the SCCS delta program (making a copy in a second directory) and then (after checking in two kernel files), sendmail. A remaining batch of kernel check-ins was done six weeks later, on June 28 (13 files). Most of the other initial check-ins during 1980, were for command-line programs, e.g., dump, ex, ld, mail, mv, pascal, rm, sendmail, vgrind. Altogether, 762 files were first checked-in during 1980.
When checking-in files to SCCS, it is first necessary to use the admin utility to create the file which will hold revisions by the delta utility. For whatever reason, this initial check-in included the delta program, but not the admin program. The remaining SCCS commands were checked-in later (beginning mid-January 1981, likely to reflect the 4BSD release two months before). None of these source files have AT&T copyright notices, nor are there any dated comments, making it inconvenient to determine if those initial check-ins used unmodified AT&T source.
However, there is a source of “sccsv4” said to be part of PWB 1.0 in UNSW tape 87 from TUHS. Ignoring the file timestamps, the same “sccsv4” is found in Bostic's and Spencer's tarballs (see summary page).
PWB 1.0 provided the first publicly-released version of SCCS in 1977, but according to The Evolution of a Source Code Control System (Alan Glasser, 1978), that was the fourth version in PWB and the ninth version (counting five versions on an IBM system). Aside from a few papers such as Glasser's there is no documentation for the earlier versions. There is no release history for the earlier eight versions, no list of features added or improved.
The two sources (CSRG and PWB) are different. Either Allman modified the AT&T source, or there was a later version of PWB from which he began. Here is a summary (the complete diff is here):
cmd/admin.c | 762 ++++++++-==========================================
cmd/alloc.c | 13
cmd/bdiff.c | 374 ========================
cmd/cmt.c | 353 ++++++++++++++++++++++
cmd/comb.c | 251 ================
cmd/delta.c | 670 +++========================================
cmd/get.c | 701 ++==========================================
cmd/help.c | 154 ==========
cmd/prs.c | 797 +++++++++++++++++++++++++++++++++++++++++++++++++++
cmd/prt.c | 425 ===========================
cmd/rmchg.c | 392 +++++++++++++++++++++++++
cmd/sccsdiff | 41 !!
cmd/scv.c | 877 !!!!!===================================================
cmd/snull.c | 581 +++++++++++++++++++++++++++++++++++++
cmd/stree.c | 293 +++++++++++++++++++
cmd/val.c | 688 ++++++++++++++++++++++++++++++++++++++++++++
cmd/vc.c | 658 ++++++++++++++++++++++++++++++++++++++++++
cmd/what.c | 63 ====
com/auxf.c | 39 ==
com/chkid.c | 19 =
com/chksid.c | 14
com/date_ab.c | 102 =====
com/date_ba.c | 22 =
com/del_ab.c | 38 ==
com/del_ba.c | 41 ==
com/dodelt.c | 131 =======
com/dofile.c | 59 ===
com/dohist.c | 162 ==========
com/doie.c | 21 =
com/dolist.c | 80 ====
com/eqsid.c | 15
com/flushto.c | 19 =
com/fmterr.c | 10
com/getline.c | 45 ==
com/newstats.c | 14
com/permiss.c | 76 ====
com/pf_ab.c | 57 ===
com/putline.c | 92 =====
com/rdmod.c | 163 ==========
com/setup.c | 81 ====
com/sid_ab.c | 18 =
com/sid_ba.c | 20 =
com/sidtoser.c | 21 =
com/sinit.c | 38 ==
com/stats_ab.c | 19 =
hdr/defines.h | 210 +============
hdr/had.h | 26 =
46 files changed, 4046 insertions(+), 21 deletions(-), 247 modifications(!), 5431 unchanged lines(=)
That shows that there were some changes to the command-line utilities (admin, delta, etc.). The larger differences are for files which are not in PWB 1.0 (prs, val and vc are documented in the AT&T manuals; while the origin of cmt, rmchg, snull and stree is less apparent).
Whether modified or not, Allman first used a feature of sccsv4 in his second check-in of sccs.c. The SCCS file shows this chunk:
^As 00009/00015/00148 ^Ad D 1.2 80/05/13 00:23:29 eric 2 1 ^Ac changed path to SCCS/s. ^Ac added chghist & help ^Ac generalized argument chomping ^Ae ^As 00163/00000/00000 ^Ad D 1.1 80/05/10 15:43:23 eric 1 0 ^Ae
The manual page for delta said:
-y[comment] Arbitrary text used to describe the reason for mak-
ing the delta. A null string is considered a valid
comment.
If -y is not specified and the standard input is a
terminal, the prompt ``comments?'' is issued on the
standard output before the standard input is read;
if the standard input is not a terminal, no prompt
is issued. An unescaped new line character termi-
nates the comment text.
That is, the developer entered three lines of text in response to a prompt, taking care to end the first two lines with a backslash:
delta sccs.c comments? changed path to SCCS/s.\ comments? added chghist & help\ comments? generalized argument chomping
I read the manual page in 1986, tried that, but found that
remembering to put the backslash on each line (with nothing else
before a newline) was too error-prone. The rcs
convention (like mail) of just marking the end of input
with a “.” was easier to work with.
Much later, when applying the same check-in message to a group
of files (in rcs, of course), it occurred to me that I
could prepare a check-in message in a file and pipe that into the
checkin
program. The BSD developers could have done something like that,
e.g., using a script to apply the backslashes. On investigation,
about 6% of the check-ins used a multi-line comment, and about
half of those were applied to two or more files.
Chris Siebenmann, in a blog entry “The origin of RCS (the version control system)”, commented that Tichy wrote RCS because SCCS was unavailable. The story is a little more complicated than that. From clues scattered here and there, it appears that Tichy came to Purdue in 1981 (not directly from CMU — he was done there in 1980), and began writing RCS (presumably in the fall). Tichy's initial papers on RCS hint that he may not have had SCCS initially, but that situation changed before the first paper came out in March 1982.
Both the initial (Purdue) and later IEEE papers have the same acknowledgements:
Acknowledgments: Many people contributed to this project, and I am grateful to all of them. Special thanks go to Bill Joy and Eric Allman from Berkeley, who thoroughly criticized my design and made sure I did not make an undesirable system. David Arnovitz implemented 2 (!) prototypes, and Tim Korb and Stephan Bechtolsheim patiently used RCS despite some problems at first.
The IEEE paper (in September 1982) adds a comment in section 4:
In this section, we compare design and performance of RCS and SCCS. We use a version of SCCS that was originally provided by Bell Labs as part of the programmer's workbench5 and was adapted at UC Berkeley to the VAX-11. Our purpose is not to criticize the developers of SCCS. SCCS has proven to be an enormously useful tool, and the basic idea of keeping a set of differences has withstood the test of time. We merely wish to discuss some annoying shortcomings of SCCS and how future revision control systems should be improved to become even more useful. We also present performance measurements that make the implementation tradeoffs clear.
Due to review delays, the IEEE paper could not have been written long after the Purdue paper. It would have been a cleaned up copy, submitted perhaps a month or so later.
The SCCS utilities which Allman checked-in early in 1981 are not in any of the other parts (such as the 4.2BSD tapes). If (as Siebenmann says), Tichy had no access to the sources for PWB, then one may surmise that Joy and/or Allman provided the SCCS utilities to Tichy to help with his testing.
When testing on a Unix system, i.e., AIX, HP-UX or Solaris, I use the original SCCS utilities. The modern BSD systems do not support SCCS in their base system. For other systems (including BSDs), there is CSSC, which is usually configured to hide the utilities behind the BSD front-end.