http://invisible-island.net/personal/
Copyright © 2013-2019,2021 by Thomas E. Dickey
In the broader sense, there are other types of configuration management tools. I am interested in tools which manage repositories of computer files.
Here is a list, ordered by my first experience with the given tool.
I started using SCCS in 1986, and used it for most project-related files for a few years. As noted here, my initial goal was to be able to store and retrieve files preserving their permissions and modification dates.
I started using RCS in 1988, after having done an evaluation to determine whether it was better than SCCS. Finding that it was, I adapted my wrapper programs to use RCS, as detailed here, and revised a program sccs2rcs to convert my archives to RCS, preserving the change-history.
Initially, I decided to manage collections of files in RCS by adding tools to control access and modify the versions of each file to the next major revision on each release. I still use the access control, but long ago decided that manipulating the version numbers was too cumbersome. Since the mid-1990s, e.g., with ncurses, I have used RCS symbolic names for revisions of collections of files.
RCS support for branches was more general than SCCS branches. I use RCS branches occasionally, with a script to simplify branching collections of files.
I used DEC's Code Management System (CMS) at the end of the 1980s as part of more than one project which was developed on VAX and SunOS systems (using DEC and Verdix Ada compilers). CMS archive files looked much like SCCS (except that a printable character was used rather than control/A).
Like my wrappers for SCCS and RCS, CMS preserved timestamps.
Around the same time, the Software Productivity Consortium
had a limited license for Apollo's
DSEE. The computer center did not make it available
to us (developers). However, I did read its documentation.
The most striking aspect about DSEE was that it
relied upon a feature of Apollo Domain not present at that
time in Unix systems: the ability to make specialized
filesystems. In the DSEE filesystem, all files were
versioned. From my directory editor ded, the current version of each file was
shown as “ls” would do, in square
brackets at the end of the filename.
Hewlett Packard subsequently acquired Apollo, to increase its market share of workstations. Because HP had no interest in DSEE, its developers left to form Atria, developing ClearCase.
Initially (while it was still a set of shell scripts), I read about CVS, but found no immediate use for it. A little later (around 1990), I setup a project tree using CVS to evaluate it versus RCS. The early results were not promising: CVS at that point relied upon the administrator to maintain a list of all of the files in the project.
Later, e.g., with XFree86 (1996–2006), I used CVS but as a developer—not the administrator.
During the same time interval of course, I encountered people who said that RCS was obsolete, and that CVS was the only way to go. Generally these were hackers such as "zenin" (Byron Brummer) who was unconcerned about file-permissions or timestamps. The hacker perspective on this is that it is too hard to keep track of what is in the repository, and that unless a check-out sets the files to the current date, the make rules will be confused.
According to "zenin", CVS could label collections of files and RCS could not. I do this anyway (with RCS). The same for branches. CVS labeling is little improved over RCS; its support for branches is the main attraction.
However, there are commercial tools to consider along the way. In 1994 I finished an evaluation of a tool called CmVision. Essentially it had been chosen because it was less expensive than ClearCase. (Using no-warranty "free" tools was not a viable option either). Besides cost, there was another factor: the project on which I was working had a resident hacker who had made a home-brew CM system using a world-writable repository of SCCS archives. The management had in mind solving this problem by buying license for a tool that was more secure against user error.
CmVision was a layer on top of either SCCS or RCS which provided
I found that CmVision did not handle RCS properly. As I recall it, it seemed that there were at the time incompatible versions of RCS to choose from; it did not work with the version supplied by Sun. We went with SCCS.
However, the user interface for CmVision was inadequate (a cumbersome GUI and a cryptic command-line program). I studied the repository files and (on my own time/resources) added a module to my directory editor and CM-tools to support CmVision. In turn, that meant that the files we retrieved from the repository had the same timestamps and executable permissions as those we checked-in.
Based on my early involvement with the tool, I was the one who administered the CmVision tool for several years (until we decided to not renew the license). At that point, I converted the trunk of the repository to a conventional SCCS archive.
On the project using CmVision we had some dissatisfied developers due to their conflicting objectives:
One of these developers said that PVCS could allow developers to setup sandboxes where they could experiment. The management decided to go that way; we got PVCS in 1998.
Incidentally, PVCS did not have a way to setup sandboxes. But its user interface ran on Windows and was more usable than the CmVision GUI. PVCS could run on Solaris, however it could not control access to the filesystem; we decided not to use it on Solaris for that reason. We migrated new development to PVCS. I was the project administrator for PVCS of course, and set about filling in the gaps in that product. For instance, it did not support branching; our process required it. So I devised a workaround to clone parts of the repository (which was more involved than simply copying files—I copied the history as well).
The PVCS tool preserves timestamps.
Toward the end of my time on that project (2005), the sandbox faction was talking about using either CVS or Subversion with Windows. However, as I pointed out to the project leads, doing that would lose all of the history in the PVCS repository, as well as losing the file timestamps, etc. Also, the Subversion port to Windows was too rudimentary. So we did not abandon PVCS.
I used PRCS with the lynx browser project from 1997 until 2015. PRCS uses RCS programs and archives, but simplifies branching. I customized PRCS to use my RCS wrappers, preserving timestamps.
I used Component Software's CS-RCS product on my Windows machines from 2001 to 2005 to manage isolated files. CS-RCS can be configured to preserve timestamps.
Starting around the end of 2005, I set up some of my Windows machines using CVSNT along with the Tortoise wrapper for CVS to manage local project repositories before staging those back to my RCS archives. That does not preserve timestamps.
I used SourceSafe on more than one project from 2005 to 2009. Like PVCS and CMS, SourceSafe preserved timestamps. Like RCS, it supported branching—but for individual developers only at the file-level. (I recall, and reading confirms, that an administrator could branch a project).
I used Microsoft's later product Visual Studio Team System (VSTS) concurrently with one of the projects with SourceSafe. VSTS had improved support for branching; it did not preserve timestamps.
I have used Subversion on more than one project since 2009. Tortoise's GUI is adequate for most uses; there are IDE plugins for others.
Though (like most GUIs) simple to use, the client program's version is tied to particular repository schemas, making it unnecessarily fragile.
Subversion provides vacuous support for preserving timestamps: it only works when importing files into a customized repository. Apparently Subversion's design interferes with solving the program; here is one of the proposed solutions.
Git's focus on the individual developer rather than a development group interferes with its acceptance in a development environment. It has the same issues as Subversion, combined with being newer and more complex.
As part of promoting the use of different tools, their developers may provide a tool for importing from a different type of repository. Those tend to address only the most common case. CVS is a target of Subversion and Git developers for instance. Some of those tools work well. For less common cases (such as RCS), the quality of the tools tends to be not very high.
A few of my website users have requested that I make readable archives for browsing; preferably in the repository format of their choice. Doing that properly requires a good export/import tool. As part of discussing mawk versus Debian, I have spent some time seeing how to do this using Git. You can see some snapshots on GitHub. I modified rcs-fast-export to do this.
However, there are some complications:
The modified script uses my RCS wrappers to fix the keyword expansion. That is slow, and aggravates memory consumption. It is workable for mawk (0.6Mb), but cannot handle the larger repositories which some have requested: xterm (3.4Mb), vile (5.3Mb), lynx (9.3Mb), ncurses (12Mb). The sizes refer to bzip2'd tar files.
In 2016, I used a different approach, which you can read about in my page on Git exports.