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

Synopsis

This is a set of tools which simpifies/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.

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 copy 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. 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:

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

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.

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, 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

Download

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

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