RCS

a really old revision control system that is still worth knowing about today

2025-11-18

Contents🔗

1. What it is
2. History
3. Warts and All
4. Use Case
5. Quickref
6. Resources

What it is🔗

It’s a version control system so you can track changes to a file and collaborate with people. Like git. But way older and way weirder.

History🔗

It was released (much like myself) in 1982, by some guy named Walter while at Purdue (unlike myself).

The somewhat more modern CVS version control system was built as a frontend / enhancement of RCS.

I’ve at least heard of CVS. I had never heard of RCS before astrid mentioned it:

https://astrid.smith.seattle.wa.us/rcs.html

It is pretty simple. If you use a version control system today, chances are you use git. RCS is like git but with no pushing, pulling, rebasing, cherrypicking, patching, or anything. You basically just check out a file for editing, and then check it back in with a log message.

Warts and All🔗

Its ergonomics are kind of weird. It ships with a bunch of utilities that you have to remember the names of, and also how to use. There’s rcs (which you don’t actually use that much), ci to check in a file, co to check it out, rcsdiff for diffing, rcsmerge for merging, rcsclean for removing files that aren’t being worked on, and rlog (not rcslog for some reason) to view the log of a file.

In practice, you’ll mostly just ci and co, with a little bit of rcsdiff.

Its primary concurrency model is the lock. You can check a file out with or without a lock which makes the file writable or read-only respectively. With a lock, only one person can edit a file at a time. Everybody else just has to wait. (Locking can be disabled if you’re not collaborating with others. Or if you are but also want to live dangerously.)

It doesn’t use http, rsync, ssh or anything at all. There’s no client-server architecture. It is entirely local. It is the only version control system I know of that simply uses the file system as a protocol.

It is file-based and colocated. It can only track changes to individual files, not to an entire codebase. Each tracked file has a corresponding “comma-v” file, which is a plain text file consisting of reversed deltas and metadata. The ,v files can colocate with the working files, or can live in a /RCS directory. They can be read and edited by hand by humans.

Use Case🔗

So why bother with RCS?

It often pays off to use as little technology as possible, for as long as you can get away with. That’s my experience at least.

RCS is a great first step along the path of incremental version control.

My use case has been having a plain text document that has grown and been revised enough that I start to think it should probably be under version control. But I’m also not mentally or emotionally ready to create a separate directory for it just so I can do a git init on a single file.

Astrid’s use case is very similar:

One situation where I think RCS is the best tool, is for small one-off files that need versioning regardless. I use it, for example, to version configuration files. I’ll check in the out-of-the-box default configuration as the first version of the file, and then make modifications. It’s really good for that, because you don’t need to create a separate repository directory and then symlink in to it from /etc or whatever.

So the solution is ci -i myfile to do an initial check-in, followed by co -l myfile to check it back out (with a lock) to continue editing it. (Or the advanced maneuver ci -l myfile to combine these steps: check it in and then immediately check it back out with a lock.)

When I’m done revising, I can check it back in, creating a new revision number and log message, and either leave it stowed or check it back out read-only until I’m ready to revise it again.

This might be just enough version control. Or I might want to actually pop this into git at some point. There are rcs2git tools out there so you can do exactly that.

This document itself started out as simply a few RCS notes for myself in a plain text file, and was placed in RCS once it began to resemble something more of a blog post. Eventually I’ll move it to my blog which is in git.

Quickref🔗

^† I have not tried to do a 3-way merge with RCS yet

Resources🔗

It is very hard to search for RCS content for a couple of reasons. It’s old and nobody uses it. “Revision control system” is an adequately generic name for what the thing does. It’s like creating an affordable car and calling it “Affordable Car.” Rich Content Messaging kind of owns the RCS market share right now.

Nonetheless here are a couple resources I have found.

• https://astrid.smith.seattle.wa.us/rcs.html
• https://www.linuxjournal.com/article/2888
• https://wiki.sdf.org/doku.php?id=rcs
• https://github.com/knuta/rcs2git/blob/master/rcs2git