Copyright © 2011-2012,2013 by Thomas E. Dickey
This is a set of tools which simpifies/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.
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. Lacking a copy of the relevant
RCS 4.x to investigate, I cannot 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.
I started writing these tools in 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. A few years later, the company's focus had shifted away from software development.
Then (this was in 1993), I had more leeway, and emailed the RCS contact address suggesting the changes that I had in mind:
coset the file's modification time match the revision date.
As it happened, Paul Eggert responded. He refused to consider any of those changes:
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.
constmismatches, the compiler is wrong.
While Eggert later posted on Usenet comments (to others) which concurred with the compiler warnings, modifying RCS itself is a dead issue.
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, I made it work with my
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 via ftp (you'll need the library):
Download via http (you'll need the library):