SCCS on the mainframe
The Source Code Control System appeared in 1972 for the OS/360 mainframe — the first system in this table.
Commits, branches and merges
A version control system records every change made to a set of files, keeps a dated history of those changes, and lets several people work on the same code without overwriting each other. Commits write changes into the repository; branches split the history so one line of work can fix bugs while another adds features; merges bring the lines back together.
01
A commit writes working-copy changes into the repository, and a checkout retrieves them. Every routine save-and-load cycle in version control is one of these two movements.
02
Branches let one line of work fix bugs while another adds features. The split is cheap to create and the two lines can grow independently until a merge rejoins them.
03
Merges create extra edges, so the history of a project forms a graph rather than a tree. Renames, splits and merges add identity problems that revision tracking must resolve.
It stores every revision of a project's files so changes can be compared, restored and, with some types of files, merged.
A commit writes working-copy changes into the repository. The working copy is the set of files on disk where edits happen; the repository is the stored history. A checkout retrieves those changes back into a working copy, which is how a developer loads someone else's work or returns to an earlier state.
Because revisions can be compared, a developer can see exactly which lines changed between two points in time. Revisions can also be restored, so a bad edit can be undone by pulling an older revision forward. With some types of files — plain text, for instance — two sets of changes can even be merged automatically.
The system also resolves identity problems: renaming, splitting or merging files creates ambiguity about which file a revision belongs to, and revision tracking has to resolve that ambiguity so the history stays readable.
The Source Code Control System appeared in 1972 for the OS/360 mainframe — the first system in this table.
Revision Control System dates to 1982 and established the local, file-per-project pattern that later tools built on.
CVS added network and concurrent features from 1986 and was rewritten in C in 1990, making shared repositories practical.
Subversion was released in 2000, improving on CVS with atomic commits and better handling of renames and directory moves.
Git, Mercurial and GNU Bazaar all appeared in 2005, moving the model from a central server to copies of the full history on every machine.
Renaming, splitting or merging files creates identity problems that revision tracking must resolve before comparisons and restores can be trusted.
Because merges create extra edges, the history of a project forms a graph rather than a tree.
| System | Year | What changed |
|---|---|---|
| SCCS | 1972 | First system, for the OS/360 mainframe |
| RCS | 1982 | Local revision control for single files |
| CVS | 1986 | Network and concurrent features added |
| CVS in C | 1990 | Rewritten in C |
| Subversion | 2000 | Released as a successor to CVS |
| Git | 2005 | Distributed model, full history per clone |
| Mercurial | 2005 | Distributed system released the same year |
| Bazaar | 2005 | GNU Bazaar appeared in 2005 |
The dates and system descriptions listed above are drawn from the documented release history of each system.