Version Control History

The history of war birds is truly awesome, like the history of the version control software. That’s why we use planes as inspiration to visualize the many version control systems through the years. It is an ongoing work and you can contribute adding comments and voting for the ones you’ve used.

Version control systems are the backbone of software development process (even the continuous delivery pipeline). As such many have been created and evolved through the years and many are still alive decades after being initially released. As one of the core development tools, version controls are hated or loved by developers and they are the fire behind many passionate flame wars. As version control developers we share the passion for this kind of software and a willingness to learn more about its history. That’s why we have created this site and we hope you enjoy it as much as we do.

The beginnings

There was a time when you stored your versions manually. Ok, for many of you this time wasn’t the 70s, but a few years back when you were at college naming your source-code archives,,,, and so on.
Well, believe it or not, there was a time without real SCMs. It was always dark and people were living in caves.

From the 1st jet fighters to the 3rd generation

In the 1945-1955 period the first jet fighters were born: the MIG 15 and Sabres ruled the air.

Later the F-4 Phamtom was born with incredible improvements over the previous generations.

In version control we included some legendary systems but the one who deserves to play the F- 4 role is certainly ClearCase, a big step ahead from any previous system and still able to fly quite fast although not a contender for modern version control systems anymore.

4th generation jet fighters

The 4th gen of fighter jets included a sensible number of legendary war birds: the F-14 and F-15 belong here and were designed back in the 70s.

In version control we include some systems that evolved through the 90s and also some quite recent creations that are a little bit ‘outdated’ in terms of pure version control features.

4.5th generation jet fighters

The jet fighters active during the 80s (based on designs from the 70s) were upgrades during the 90s with new avionics based on the new microcontrollers. These upgraded jet fighters were known as the 4.5th generation.

In version control we included here the version control systems that were clearly better than the previous file based generation in terms of underlying technology but which didn’t ‘cross the chasm’ to become part of the mainstream distributed version control age.

5th generation jet fighters

In 2005 the version control status quo was broken: a new age of version control was born, the distributed version control systems, leaded by Linus Torvalds himself with Git.

DVCS was not only about being disconnected but about using fast and reliable merging (saying good bye to the preceding dark age of Subversion).

GitHub (2008) turned Git into a social network for programmers and nowadays is very strange not to find version control related stories on top programming news sites on a daily basis.

The open source world moved to DVCS first (all major oss projects abandoned SVN in the 2008-2010 period) and now the enterprise is catching up.

Next Generation

Version control is in constant evolution as a core piece of modern development practices such as Continuous Delivery and Agile Development.
It is not easy to figure out what is going to be next in version control, only 10 years ago it wouldn’t have been easy to find that DVCS was going to be the next big thing.
But, as version control developers ourselves, there are some important steps ahead that we envision:

  • Going Semantic: we already started the trip towards semantic version control with Understanding the code structure to merge files (and diff) is something developers have been asking for, and we believe it will be great to boost refactoring and code quality. Maybe it will become part of our daily workflow (see semantic history) and there won’t be way back, like code completion :P
  • Extracting valuable information from the version control to assist the developer while coding: annotate while you edit is not new, knowing whether a block of code has been involved in many modifications or not, or if it is buggy, or if it was modified by many people will let you make more informed decisions. Version control is not just a delivery mechanism (checkin and that’s all) but a productivity tool for the programmer, something that stores valuable data that properly mined can be really helpful.
  • Enterprise level DVCS: finally eradicating arcane working patterns like pessimistic locking, enabling flexible collaboration among distributed teams while still adhering to the required regulations and security policies required by enterprises.
  • Better visualization tools: to make easier to understand changes, branching and merging, to track fixes and new features.
  • And of course even better performance and revisited usability.

Evaluate Plastic SCM
and get one of these T-Shirts

Follow our Evaluation Guide, complete the examples step by step, send us your results back and we will send you one of these awesome T-Shirts!!

I want it!

Join us and comment

We’re trying to catalog here all the version controls to date, collecting information for contributors and usage information: you can click on each version control and tell whether you’ve ever used it or if you’re still using it, and also submit comments.

comments powered by Disqus
Wright Brothers

SCCS 1972

SCCS goes back to 1972, and was later ported to Unix. CSSC ("Compatibly Stupid Source Control") is GNU's clone of SCCS; it's still maintained, but not recommended for general use.

The CSSC documentation says "GNU CSSC was originally based on the public-domain package MySC, which was written by Ross Ridge."

Source: comments from here

Montgolfière Ballon

CMS 1978

OpenVMS has a version control system called CMS (Code Management System). Also left out Digital Equipment Corporation's CMS (Code Management System) from the late 1970's, probably still used on some VMS systems. CMS CMS

It was only available on VMS (now on OpenVms).

It was full featured and had a great command line and X-Windows interface.

Source: comments from here



My first version control system was called UPDATE, available on the CDC6600 and later Seymour Cray origin systems. Circa 1969.

Source: comments from here


Delta Decks on Punch Cards 1960

If you really want to to truly ancient history, you have to go back to delta decks on punch cards. That was 780's for me, I don't remember the name.

Source: comments from here

Fokker DR1

RCS 1982

Then 1982 came and RCS was released. RCS is not a huge piece of technology, but you can still find it around in Unix distros. It is simple and straight to the point.

One nice feature was that text changes were stored as deltas (pretty important, considering hard drives used to be small!). Deltas are still used nowadays by most SCMs.

Some RCS drawbacks worth mentioning:

  • It is text only.
  • There is no central repository; each version-controlled file has its own repo, in the form of an RCS file, stored near the file itself. For example, the RCS file for /usr/project/foo.c is /usr/project/foo.c,v -- or a little better, in a subdirectory, /usr/project/RCS/foo.c,v.
  • Developers make private workspaces by creating symbolic links to RCS subdirectories – say, a symlink from /usr/home/john/RCS to /usr/project/RCS.
  • Naming of versions and branches is downright hostile. A version might be named 1.3, and a branch might be named 1.3.1, and a version on the branch might be named


Envy Developer

ENVY/Developer is a source code and configuration management system for SmalltalkLanguage and JavaLanguage, offered by IBM, and integrated into their VisualAge family of products.

Source: here


Aide-De-Camp 1984

Another obscure one, I once used: Aide-De-Camp from 1984. Far more powerful than RCS etc. However when I was I using it (early 90's) it was too slow. Cheers Mark Levison Agile Pain Relief Consulting.

Source: comments from here



It seems you miss cpold in the list (reference : here in french) ;-)

Source: comments from here


Visible Razor

Visible Razor is a commercial product which was very much a client-server tool which only allowed one user to check out a file at a time. It did have one interesting feature: every check out or commit of a file needed to have an issue (from the integrated issue tracker) associated with it.

Source: comments from here

Fiat G.50B

CVS 1990

It all started with CVS (Concurrent Version System) in 1990. It was able to handle multiple versions being developed concurrently on different machines and stored on a central server. The client-server age was upon us and developers took major advantage out of it.

CVS was able to handle versions in a decent way. And it even supported branching and merging, though it wasn’t very good at doing it. That’s one of the reasons many people are scared about the "branch" word and the "merge" words.

CVS didn’t track directories or filename changes (no refactoring allowed here!) and heavily relied on locking the whole repository. It is outdated now, but it worked in the 90s! (If you have it, just walk away and go on to something else!)


Microsoft Delta

It was the internal software used by Microsoft, MS saw an opportunity to cash in on the niche and productized it. It got replaced by VSS when MS acquired OneTreeSoftware.

Source: comments from here



DSEE on Apollo workstations was the predecessor to ClearCase

DSEE is Domain Software Engineering Environment.

One of the big deals was the build system and the concept of using dynamic and bound configuration threads as part of the system.

Source: comments from here



Does anyone remember BCS? (Baseline Configuration System.) We used to use it as an add-on to CVS. It used links to shared files in a baseline checkout unless you were editing the file. Complete nightmare! It seems to have disappeared without trace now though.

Source: comments from here

Mitsubishi A6M Zero

PVCS 1985

Polytron Version Control System (PVCS) was initially released in 1985 and then went through a series of mergers and acquisitions: Polytron, then Sage, Merant, and finally Serena.

It’s an old, outdated system (initially designed to avoid branching/merging, using file-locking instead), but it’s still supported by Serena Software.

Supermarine Spitfire

Subversion 2000

Subversion (SVN) was conceived as “enhanced CVS” and its developers hit their target: it is better than CVS. Period.

While it was created in 2000 (much later than the other version control systems in this age) it used quite outdated concepts and that’s why it is classified here.

Although systems like ClearCase were perfectly capable of branching and merging already, SVN educated an entire developer generation on the following dogma: fear branching and merging at all cost! This caused environmental damage that persists to this day, only starting to be healed by the new DVCS generation.

SVN was close to P4 in features, and spread like crazy: more than 5 million developers around the world use SVN on a daily basis. Huge!

SVN is extremely simple to use and evangelized everyone on the “mainline development model”. Error-prone (break the build!) on non-toy projects, it helped developed techniques like “continuous integration” as a way to “avoid integrations”. While the idea is good, most of the surrounding concepts were clearly limited by the tool itself.

Linus himself raged against SVN when he first introduced Git back in 2006.

During 2009 and 2010, all major open-source projects on earth gravitated away from SVN. A good sign of how wrong SVN was. But it’s still big and won’t die for ages.

Messerschmitt Me 262

VSS 1994

Visual Source Safe was the first version control for many developers. It forced to use a “locking” approach, discouraging parallel development and creating a huge "fear of merging".

Slow, error prone, and utterly limited, VSS has been one of the most-used systems by Windows developers around the world. It is still in use, spreading pain and fear among good- hearted coders.

VSS was entirely graphical, which was probably one of the reasons why it was widely adopted (along with being closely tied in with Visual Studio distributions).

McDonnell Douglas F-4

ClearCase 1992

In 1992, one of the major beasts in the SCM world was born. ClearCase was clearly ahead of its time and for some it is still the most powerful SCM ever built.

Outdated, slow moving, overpriced, and overly complicated to administer (in the early days, you had to generate a new Unix kernel to run the beast!), good-old CC isn’t the cool guy anymore -- you can hardly find anything positive about it on the net. But it’s still very good at branching and merging and still has unique features, such as its legendary “dynamic views”. While powerful, CC came from a time when disk space was scarce and networks were mostly LANs, with no concerns for things like latency or working through firewalls.

Atria (the developer of ClearCase) merged with Pure (which was run by Reed Hastings, later the head of Netflix), was purchased by Rational and then IBM. And lo, the powerful CC stopped evolving. Well, it did evolve towards UCM in the early 2000s, which basically got rid of all the good things and left the weak ones, together with a huge price. Not a very good idea.

ClearCase is still one of the most-used SCMs in the corporate world, and certainly one of the revenue leaders.


StarTeam 1995

StarTeam was developed by Starbase Corporation, later acquired by Borland which in turn was purchased by Micro Focus.

It was originally released in 1995 and it is still under development.

Source: here


Rational CMVC 1992

Rational CMVC anyone (1990ish) or is that a little too obscure for anyone else? It had views based on activities and only ran on Rational's own R1000 hardware, although it did turn up later on Suns.

Source: comments from here


Continuus/CM Telelogic CM Synergy

Continuus/CM (which is now also taken over by IBM). It probably combines all the bad features of all other commercial SCM, while being glacially slow, horribly expensive, a prime example of terminally inconsistent interfacing (I support this SCM from hell already 10 years).

Source: comments from here

Grumman F-14 Tomcat

Perforce 1995

F-14 is a legend in the jet fighter world and P4 is a legend in the version control space. Probably both are a little bit outdated but they have been there for a while and they made history.

Perforce (P4) is one of the independent vendors totally focused on version control, battling for the SCM gold. It is still one of the market leaders among mid-range companies with huge teams, and it has a strong presence in some market niches, such as the gaming industry.

When it was released in the mid 90s, P4 was one of the most affordable and powerful systems to date. Worlds ahead of VSS and CVS, it was never at the level of Clearcase. But it was able to clearly beat CC in cost, performance, and ease of use.

Being centralized and not very good with branching and merging (branches are implemented as subdirectory trees – although they got slightly better with streams in the latest releases) P4 doesn’t seem to be the best option for the future, but it is rock solid, mature, and well established. That will help it keep growing. At the time of this writing, P4 is the biggest code repository inside Google. Cool!

Dassault Mirage 2000

Accurev 2000

Raised in an age of darkness (when SVN ruled the world), AccuRev was developed as an entirely new approach to source control. Its original way of doing things still seems new to lots of developers nowadays.

AccuRev has strong support for branching (“streams” in its jargon) and merging. It has played a valuable role in helping the community move away from ClearCase and older tools like CVS.

Lockheed C-5 Galaxy

TFS 2005

Microsoft, wanting to play a role in the SCM/ALM market, came up with Team Foundation Server (TFS). It’s an effort to heal the pain caused by its own VSS devil.

While TFS is not very strong as a source-control system (kind of a new guy on the block, but using previous-generation technology), it comes fully packaged with a huge set of tools, from issue tracking to test management, in the pure "corporate-huge-integrated-thing-style".

You won’t be doing branching, merging, or DVCS if you go for it, but maybe your company already purchased it, along with an MSDN subscription.

We didn’t associate a fighter jet to TFS because independently of how good it is, it is not definitely a fast moving, agile, and intuitive version control. Not a jet fighter.

Boeing B-52 Stratofortress

RTC 2005

Initially released in 2005 Rational Team Concert (also known as Jazz) is not only a version control system but a full ALM deeply integrated with the IBM Eclipse code.

We didn’t use a jet fighter to illustrate RTC but a slow and heavy weight B-52 bomber. It definitely has a lot of power but it won’t get you there fast.


GNU Arch 2001

Initially released back in 2001 Arch was one of the first distributed version control systems. Arch is an open source project.

Arch features advanced branching and merging and the ability to add cryptographic signatures.

It was critized for being difficult to use and to have a too large command set.

Source: here


Aegis 1991

It is an open source version control system heavily linked to test driven development practices.

It is defined as a ‘transaction based’ software configuration management system.

Source: here




General Dynamics F-16 Fighting Falcon

Bitkeeper 1999

BitKeeper was one of the innovators in the DVCS field. Designed by Larry McVoy (who previously worked on TeamWare, Sun’s internal version control system, built on top of SCCS, long evolution story here...) it rose to fame in 2002 when the Linux kernel development team started using it. A huge flame war started, with some developers complaining about using commercial tools for the world’s premier open-source project.

Things only got worse in 2005 when fights with the core kernel developers grew even bigger. BitMover, the company behind the product, became concerned about people reverse- engineering their code. They discontinued support for open-source development and, ironically, thus prompted the creation of Git to fill the gap.

Source: here

Eurofighter Typhoon

Darcs 2002

Darcs (Darcs Advanced Revision Control System) is another open source attempt to get rid of CVS and Subversion. It started in 2002 and has been continuously evolving since then.

The major shortcomings of Darcs have been performance and its different way of handling history: instead of managing “snapshots” (commits or changesets) it manages patches, but in a way that makes traversing history difficult to understand (a current status may have not been a real snapshot).

Lockheed Martin F-22 Raptor


Linus Torvalds, the father of Linux himself, designed and implemented the first version of Git (almost over a weekend, in pure-hacker style) to give his kernel developers an alternative to BitKeeper. Linus not only did the original design (simple, clean, genius), but helped promote the project with his unique style. (See

During his famous speech, he heavily criticized (ok, insulted) CVS, SVN, and Perforce: “Subversion has been the most pointless project ever started”, “If you like using CVS, you should be in some kind of mental institution or somewhere else” and finally “Get rid of Perforce, it is sad, but it is so, so true”.

You can love him or hate him, but he definitely made his point: the Middle Ages were over and now distributed systems were to rule the world, including removing the arcane fear of branching and merging, a key concept behind every DVCS.

During the next years, every major open-source project migrated away from Subversion towards Git (and provided a really huge, huge hosting service), making it the strongest and coolest SCM on earth.

Git is based on a DAG structure (Directed Acyclic Graph), in which the main unit of change is the changeset. It implements full merge-tracking, but at the commit level instead of the individual file revision level (as, for instance, ClearCase does). It is extremely fast, with the only caveats being management of large binary files and the requirement to replicate repositories in their entirety.

Git is clearly influenced by its kernel roots, and it’s obviously not the easiest thing on earth to use . But it will definitely be the SCM of the next decade. Check out this awesome book.

Sukhoi PAK FA

Mercurial 2005

Mercurial (Hg) was first announced on April 2005, also rushing in after the BitMover decision to remove support for the free version. Hg is also one of the key open-source DVCSs, along with Git. They can even work together quite well: Scott Chacon, the Git evangelist and one of the best SCM tech writers ever, wrote a nice integration -- see

But Hg differs quite a bit from Git in terms of design. They share the concept of commit/changeset as the unit of change. Git implements this based on trees; each tree points to an older tree, and so on – hence the DAG. With Hg, every changeset is a flat list of files and directories, called a revlog.

(For more on Hg, including internals, see and

Mercurial provides very strong merging, but it’s a bit different from other SCMs in its branching model: it has “named branches” but the preference is to create a new repository as a separate branch instead of hosting “many heads” inside a single one.

Joel Spolsky has written an extremely good Hg tutorial (, which will help a lot of new users. Spolsky’s company, Fog Creek Software, has recently released Kiln, a commercial wrapper around the Hg core.

To better understand why Git and Plastic SCM merging is better the one provided by Hg check this blog post.

Plastic 3 Stealth Sword

Plastic SCM 2006

Plastic is a DVCS with a focus on branching and merging (it features the most powerful merge engine) and ease of use through visualization

Plastic breaks most of the barriers of open source DVCS:

One of the key features in Plastic SCM is the way it visualizes branches and merges through the Branch Explorer.

Plastic speaks the Git network protocol and can directly push and pull to Git servers with GitSync.

Unlike most of the DVCS it doesn’t come from open source: it was designed with commercial use in mind from day one.

Plastic is built around the concept of parallel development, encouraging use of the "branch per task" pattern (feature branches).

Plastic is free for open source and a Community Edition (free for teams up to 15 developers) is available too.



Bazaar (bzr) is another open-source DVCS, which tries to provide some fresh air to the SCM world. While less used than Git and Mercurial, Bazaar features interesting features, such as the ability to work in a centralized way, if needed. (The “pure” DVCSs didn’t include central servers in their original design.)

Bazaar was developed by Canonical (yes, the Ubuntu company!) and became GNU in early 2008.


Fossil 2006

Fossil was initially released in 2006 and belongs to the DVCS era. It was created by the Richard Hipp (of SQLite fame) and it includes interesting features like an integrated wiki and bug tracker.

Source: here


Open CM 2010?


Plastic 4 Stratospheric Arrow

Plastic SCM 2006

Plastic is a DVCS system designed with commercial use in mind instead of open-source projects (unlike Git and Mercurial). Plastic was first released in late 2006, featuring strong branching and merging, including full merge tracking and rename support in merges. It provides a highly graphical working environment, with many data-visualization capabilities, including a 3D revision tree). This distinguishes it from DVCSs that are oriented toward the hard-core, CLI-oriented hacker community.

The motivation of Plastic’s developers (BTW, I’m one of them) is to target small and medium teams, closing the gap between expensive high-end systems like ClearCase and low-end ones like SVN.

Plastic is built around the concept of parallel development, encouraging use of the "branch per task" pattern (feature branches). It can handle thousands of branches without breaking a sweat. Plastic is also distributed, supporting disconnected development, pushing and pulling of changesets on branches, and conflict resolution.

A Community Edition of Plastic SCM was launched in November 2010.

Plastic 5 Galactic Pulse

Plastic 5 2013

Plastic is a DVCS system designed with commercial use in mind instead of open-source projects (unlike Git and Mercurial). Plastic was first released in late 2006, featuring strong branching and merging, including full merge tracking and rename support in merges. It provides a highly graphical working environment, with many data-visualization capabilities, including a 3D revision tree). This distinguishes it from DVCSs that are oriented toward the hard-core, CLI-oriented hacker community.

The motivation of Plastic’s developers (BTW, I’m one of them) is to target small and medium teams, closing the gap between expensive high-end systems like ClearCase and low-end ones like SVN.

Plastic is built around the concept of parallel development, encouraging use of the "branch per task" pattern (feature branches). It can handle thousands of branches without breaking a sweat. Plastic is also distributed, supporting disconnected development, pushing and pulling of changesets on branches, and conflict resolution.

A Community Edition of Plastic SCM was launched in November 2010.