http://invisible-island.net/ded/
Copyright © 2011-2021,2022 by Thomas E. Dickey

Synopsis

This is a set of tools which simplifies/extends RCS, as well as providing useful features that are shared with the sccs_tools package.

History

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:

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.

I started writing these tools in late May 1988:

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.

Features

There are many features, but these are the ones that I use all the time:

Influence

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:

As it happened, Paul Eggert responded. He refused to consider any of those changes:

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 ci/co, which did part of what I suggested.

Some clarification is needed for the setuid feature. The rcs utilities do provide some support for setuid operation, as documented in the ci manpage:

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.

Other Toolsets

The checkup utility (and corresponding support in ded) support some other revision control toolsets.

SCCS Tools

After writing checkup in 1988, I made it work with my SCCS tools.

CmVision

I added support in 1994.

CVS

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 version information.

PRCS

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

BitKeeper

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.

Subversion

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.

GIT

I am not likely to add support for this, noting that there is very little useful meta information stored in a GIT-ball.

Documentation

Changes

Download

Download both files (you'll need the library):