Copyright © 2011-2021,2022 by Thomas E. Dickey
This is a set of tools which simplifies/extends RCS, as well as providing useful features that are shared with the sccs_tools package.
Before writing these tools, I had written a set of tools to simplify/extend SCCS.
That was in a different company.
New company, old problem.
However there were additional people involved.
Management recognized the problem, since our service organization had not provided a reliable way to manage the prototypes that we were developing.
Eric Marshall (part of my group of "explorers") recommended that we use RCS, since it was supposed to be better than SCCS. Since I had practical experience with SCCS, we had a disagreement. I resolved the disagreement by investigating and validating the differences between the two. Eric, by the way, used a Sun3 workstation at that time; I developed on an Apollo. Apollo (unlike Sun) did not provide RCS, so I compiled RCS for myself.
At the time of course, CVS was not under consideration. It was still just a collection of shell scripts.
There were several points to investigate. These are what I recall from Eric's comments:
The first three are indisputable. The effect of the archive-file organization depends upon your workflow. For moderate- to large-projects (50-5000 files), only a small fraction of files change in a given commit. In ncurses for example, with about 1200 files, less than 1% of the commits touch as many as 10% of the files; typical commits touch about 1% of the files. Our projects in 1988 were smaller than that.
In retrospect, there are a couple more factors not considered at that point:
rcshistutility was not available then. Reviewing old changes in SCCS is simpler (one can read the file directly)
On the other hand, I had my own concerns. This was probably
using RCS version 4.2 or earlier. The tool had no reliable way to
maintain file modification times. When I first wrote this in
mid-2011, I lacked a copy of the relevant RCS 4.x to investigate
and could recall whether the
-d option was missing
(4.3, a year later, has it), or whether it was the fact that
retrieving a file using
co would always set its
modification date to the current time. Either way, it was
unsuited to our needs.
Given that, I agreed that we could use RCS, but that I would
provide wrappers to implement the timestamp improvement.
Modifying the RCS programs themselves was out of the question (we
kept in mind the company lawyers who would steer clear of
anything related to licensing). Revisiting this page in November
2014, I see that the pertinent version could have been RCS 4,
released as part of
4.3BSD Tahoe or even RCS 3 in
4.3BSD. In either case, at that point in time Tichy (the
original author of RCS) had left Purdue to return to Germany
1987). Most of the development after the end of 1983 had been
done by others. Oddly enough (though included in 4.3BSD), the
actual source license was noncommercial. For commercial use (as
registration was required. That changed a year later. This is
what it says in the Free Software Foundation's
RCS Walter Tichy 1989-03-20 Licenses use of RCS with our choice of terms.
I started writing these tools in late May 1988:
are wrappers for
preserve file-modification times. This is useful for example, in
checkup utility which reports files which have
been modified since they were last checked-in. Of course this is
less accurate than storing a snapshot of the original file on
your disk for reference (as
subversion does) but it
is much faster. The ded program uses
the same library function as
checkup to provide
similar information. Comparing file contents rather than
timestamps for this purpose would be unacceptably slow.
There are many features, but these are the ones that I use all the time:
checkoutpreserve file modification times.
checkoutwork with setuid permissions.
copyutility has a preview (no-op) mode, and progress meter. It also copies symbolic links correctly.
permitutility manages access control lists.
Some readers ask, did you submit your changes to the RCS developers.
The answer is, "something like that". As I recall it, even before the 4.3 release RCS was said to be GPL. Our policy was to stay clear of things that might get the lawyers confused (in fact, the license switched from BSD to GPL in May 1989). A few years later, the company's focus had shifted away from software development.
Then (this was after the DAT project during 1990-1991), I had more leeway, and emailed the RCS contact address suggesting the changes that I had in mind:
modify the "-d" option, or add an option to make
co set the file's modification time match the
modify the RCS utilities to work properly as setuid
programs. They did not for instance use the
access function properly.
compiler-warning cleanup. There were many
As it happened, Paul Eggert responded. He refused to consider any of those changes:
no one would use the option for setting file-modification time. So there was no point in adding it.
setuid code should not pay attention to
Also, he was only interested in POSIX, uninterested in whether the programs would work on Solaris (which did not, according to Eggert) have POSIX setuid semantics.
Discussing a little further (after I went to the library to check), POSIX was equated with Linux, and whatever paper I had read gave the wrong information.
const mismatches, the compiler is
While Eggert later posted on Usenet comments (to others) which
concurred with the compiler warnings, modifying RCS itself is a
dead issue. RCS 5.6 (1991/11/22) provided the
-M” option for
co, which did part of what I
Some clarification is needed for the setuid feature.
The rcs utilities do provide some support for setuid operation,
as documented in the
chmod'd to have setuid permissions.
rcscleanalso is mentioned (does anyone use that program?)
rcsutility must be run by the administrator. It is not designed to by run with setuid permissions. If it is
chmod'd for setuid permissions, odd things happen, e.g., your working files will be owned by the administrator.
This scheme is reasonably portable (testing with root-setuid and non-root setuid Solaris 10, Linux, FreeBSD, NetBSD and OpenBSD). The system version of OpenBSD's rcs utilities do not work properly for a non-root setuid (the administrator owns all of the working files), but the original rcs source code when compiled for that platform works as described.
However, this means that only the administrator can add new
archive files. Instead, my tools make that feature a part of the
checkin utility, subject to directory permissions
set using the
permit utility. An administrator is
needed to unlock files and to remove archive files.
checkup utility (and corresponding support in
ded) support some other revision control
checkup in 1988, I made it work
with my SCCS tools.
I added support in 1994.
I added support in 1998, to help with XFree86 development, e.g., to identify changed files, and rework changes into useful commits.
CVS records in each directory the timestamps for
the files as they are extracted from the archive. It also records
I thought it would be nice, in 1999. But PRCS (written in C++) is not as portable as one would like. Because of that, I use it only for lynx.
PRCS records in the top of the project tree a
file listing the timestamps and permissions to assign to each
I spent some time investigating this in (June 2003), intrigued by its marketing, curious to see what the differences were from SCCS underneath.
However, even in 2002 it was well-known that BitKeeper's license prohibited any interface such as I might have found useful.
I added support in 2009, to help with a project which uses
Tortoise. That is nice, as far as it goes, but
Subversion is fragile.
The interface to
Subversion shows the revision
number, which is its closest equivalent to versions. Likewise, it
shows as the "lock owner" the committer.
I am not likely to add support for this, noting that there is very little useful meta information stored in a GIT-ball.
Download both files (you'll need the library):