If you are a young developer chances are that Git is the only version control system you know and use. There is nothing wrong with it, as this is probably the best one. However, it’s worth to know that other systems exist too and sometimes offer interesting features as well.

In this post I present a list of VCSs I came across during my programming education and career.

Concurrent Versions System (CVS)

I admit I never used this one. The only contact I had with it was often when I criticized SVN. More experienced developers used to say:

Dude, you haven’t used CVS, so shut up!

This is probably the oldest VCS, at least from the ones that were widely adopted. It was first released in 1986 and last update is from 2009. Initially it was a set of shell scripts, but later it was rewritten in C. The “features” that led it to die out included:

• Non-atomic operations – when you pulled (whatever it was called) from the server and for example your connection broke, it was possible that only part of files were updated.
• No diff for changing filename – it was stored as deletion and addition anew.
• No file deletion

Subversion (SVN)

Subversion is a more or less direct successor to CVS. It was designed to solve its most dire problems and became a de-facto standard for many years. I used SVN in my second job for a long time (after that we managed to migrate to Git).

SNV offered atomic operations and ability to rename files or delete them. However, compared to Git it still suffers from poor branching system. Branches are in fact separate directories in the repository and to apply some changes to many branches you have to prepare a patch on one branch and apply it to the other. There is no branch merging and creating a new branch is not a simple and cost-free.

One more important difference: SVN (and CVS) are not distributed, which means they require a central server where main repository copy is stored. It also means that they can’t really be used offline.

Still, Subversion has (or had) some upsides over Git:

• Because of it’s directory-based structure, it is possible to checkout any part of the tree. For example, you could checkout only assets if you are a graphic designer. This led to a custom to keep many projects in one huge repository.
• Subversion was slightly better at handling binary files. First of all, Git was reported to crash with too many binaries in the repo, while SVN worked fine. Secondly, those files tended to take a bit less space. However, later Git LFS was released, which in tipped the balance on Git side.

Because of it’s features, SVN is still used today not only as legacy VCS, but sometimes as a valid choice. For example, Arch Linux’s ABS system was ported from RSync to SVN not too long ago.

Mercurial (HG)

Mercurial and Git appeared more or less in the same time. The reason was that previous popular VCS I was not aware of (BitKeeper) stopped to offer its free version (now it’s back again). And the problem was that Linux kernel was developed using BitKeeper. Both Mercurial and Git were started as successors to BK, but finally Git won. Mercurial is written mostly in Python with parts in C. It was released in 2005 and is still actively developed.

I haven’t actually ever found any crucial differences between HG and Git. For a longer period of time I prefered the former as I felt that it’s better at conflict solving (Git was failing to resolve basically every time back then). Also, BitBucket was a hosting for Mercurial repositories and it offered private repos, which Github did not. It’s worth noting that back then BitBucket did not support Git (it started in 2008 and Git support was added in late 2011).

I know a couple of teams that choose Mercurial over Git for their projects today.

Darcs

Darcs always felt a bit eerie to me. It’s written in Haskell and the language’s ecosystem is probably the only place where it gained some popularity. It was advertised as truly distributed VCS, but probably Git caught up since then, because differences between those two seem not that important. Plus, Darcs still does not have local branches.

Latest release of Darcs is from September 2016.

Bazaar

With its name derived probably from famous Eric Raymond’s essay, Bazaar is another child of year 2005 (like Mercurial or Git). It’s written in Python and is part of GNU Project. Because of that, it gained some popularity in open source world. It is also sponsored and maintained by Canonical, creators of Ubuntu.

Bazaar offers choice between centralized (like SVN) and distributed (like Git) workflows. Its repositories may be hosted on GNU Savannah, Launchpad and SourceForge. Last release was in February 2016.

Fossil

Written in C, born in 2006, Fossil is interesting, though not really popular, alternative to other version control systems. It includes not only files, revisions etc., but also bug tracker and wiki for the project. It also has built-in web server. It’s under active development. Most prominent project using Fossil is probably Tcl/Tk.

Pijul

Pijul is a new kid in the block. It’s written in Rust and attempts to solve performance issues of Darcs and security issues (!) of Git. It is advertised as one of the fastest and having one of the best conflicts-resolving features. It is also based on “mathematically sound theory of patches”.

It still does not have version 1.0 though, but it’s definitely worth watching, as it might be a thing some day. You can host your Pijul repository at nest.pijul.com.

Summary

Name	Language	First release	Last release (as of May 2017)
CVS	C	1986	May 2008
Subversion	C	2000	November 2016
Mercurial	Python, C	2005	May 2017
Darcs	Haskell	2003	September 2016
Bazaar	Python	2005	February 2016
Fossil	C	2006	May 2017
Pijul	Rust	2015 (?)	May 2017
Git	C	2005	May 2017