Copyright © 2011-2015,2017 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:

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.



RCS Tools

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:

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 via ftp (you'll need the library):

Download via http (you'll need the library):