rcs - chrisman/knowledge GitHub Wiki
title: RCS subtitle: a really old revision control system that is still worth knowing about today date: 2025-11-18 author: dozens
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.
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.
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.
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.
<style> td { vertical-align: top; } </style>Initialize ci -i file
(This deletes the working file,
but it is safely stored in file,v)
Edit co -l file
(locks the file for editing)
Commit ci -l file
Delete a rcs -orange 1.3 (e.g.)
branch (why's it called orange?????)
View log rlog file
Diff recent rcsdiff -c file
commits
Diff two rcsdiff -r1.1 -r1.2 file (e.g.)
commits
Merge two rcsmerge -r2.8 -r2.4 file
branches^†^
Turn off rcs -U file
strict locking
Turn it rcs -L file
back on
^†^ I have not tried to do a 3-way merge with RCS yet
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.