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:

command-line options of RCS are simpler.

RCS has better support for branching.

RCS supports symbolic revision labels.

Accessing the "tip" revision in RCS is faster than in SCCS
due to the way it is stored. Most uses of a given archive file
use only this information.

Accessing older revisions in RCS can be slower than in
SCCS. On the other hand, this is infrequently used.

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:

reviewing very old changes.

The rcshist utility was not available then.
Reviewing old changes in SCCS is simpler (one can read the file
directly)

how to remove old changes.

In a later project using SCCS, we found that SCCS could not
cope with a customer request that we purge a set of
revisions from archives. SCCS utilities marked the revision as
deleted, but the information was still in the archive. Editing
the file directly was the solution; RCS would have done this.
But reviewing old changes in RCS takes more skill than with
SCCS.

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
(August
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
done by
MKS),
registration was required. That changed a year later. This is
what it says in the Free Software Foundation's
copyright.list (see
this page):

RCS Walter Tichy 1989-03-20
Licenses use of RCS with our choice of terms.

The checkin and checkout utilities
are wrappers for ci and co, which
preserve file-modification times. This is useful for example, in
the 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.

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:

modify the "-d" option, or add an option to make
co set the file's modification time match the
revision date.

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
const mismatches.

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
access.

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.

regarding const mismatches, 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 ci manpage:

An administrator is needed, to act as the
setuid-owner.

The ci and co utilities are
chmod'd to have setuid permissions.
rcsclean also is mentioned (does anyone use that
program?)

The rcs utility 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.