A Short History of Revision Control


Source code revision control has come out in three main versions, at least from the point of view of the Unix world. Back in 1975, SCCS (which stands for Source Code Control System) was introduced by Rochkind of AT&T. Before that time, source was usually stored on punch cards and it was hard to imagine keeping around more then one copy of your program. But by 1975, disk storage was available and this is where your source code was kept.

But disk was expensive, so you still didn't keep many versions of your code. SCCS solved that by keeping one complete version of your code, plus incremental updates. It also introduced version numbering, along with branching versions, so you could have version 1.1.1, and 1.2.5, etc. Because only incremental updates were saved, not much disk space was used; yet you could regenerate any back-version you wanted.

This system was cumbersome to use, and hardly anybody bothered with big, bushy, branching source trees.


RCS (Revision Control System) introduced the ability for several people to work on the same source code, while retaining the version control of SCCS (including branching source trees). It came out in 1985 or so, and is the work of Walter Tichy at Purdue University.

Multiple access to the same source was implemented by allowing only one writeable version of a file to be checked out at a time. You would check out a file with a lock, edit it, and then check it back in. At that point, your teammate could check it out, edit it, and check it back in. If you wanted to check out a file that was already checked out by someone else, tough luck. You had to go find them and beat them up until they gave up the file.

In practice, you would wind up checking out a read-only copy of the code, make it writable (or take a writable copy), make your edits, and then merge them with a writable copy when you could get it.

RCS caused a number of conflicts in the workplace, and could have been responsible for originating the term "code ownership".


CVS (Concurrent Versions System) by Grune, Berliner, and Polk came out in 1986, but only recently has it gained wide-spread use. Its worst feature is function bloat; its best feature is that it allows several parties to work on the same source file without locking it. This solves the RCS problem where somebody would "run off" with a file for weeks, monopolizing that part of the source tree.

CVS accomplishes concurrent writable access by merging updates made by multiple parties and warning them when their updates conflict. You can incorporate your partner's changes into your working copy at any time, and you can commit your copy which means that your copy will be merged into your partner's, upon his/her request.

People working on the same source file will still have to resolve any conflicts detected by CVS. One wonders how this human interaction will be smoothed by fourth-generation version control systems.