Version Control Systems

Version control has been a hobby of mine for a long time, since I started using RCS a long time ago, then switched to CVS, mostly because I used it within the FreeBSD project and the most documented & used one at the time.

Centralized VCS

This is the oldest type of VCS, some people still uses them because they prefer a single reference repository for everything (the FreeBSD Project is one of them).

The most well-known examples of such are the ancient GNU RCS, CVS and the more modern Subversion and Perforce.

All centralised VCS (CVS, Subversion or Perforce) share the same flaw in their design: offline work is generally severely limited and synchronization of multiple repositories can be a problem especially if one wants to keep history (although svk works around most of SVN’s limitations).

I finally got tired of CVS limitations and, again because FreeBSD started using it, switched to Perforce, a nice but proprietary VCS. Perforce is powerful and fast but after 5 years, I felt that a centralised VCS was not for me as I fought it to keep 3 different repositories in sync (my laptop’s, the one at home and the last one at work).

Distributed VCS

In the meantime, a new breed of VCS has arisen: decentralised/distributed VCS.

BitKeeper was the first one to appear. Its design is heavily based on SCCS with enough added code to record the metadata needed for cloning, branching and associated workflows.

In 2002-2003, there was not much choice (BK being not usable due to its license and the attitude of its leader, L. McVoy) and I then switched to GNU Arch. After two years of use enjoying its decentralised nature, I begun to tumble on some of its limitations and I started to look at alternatives including Darcs, Monotone, Mercurial and others.

I could not go back to centralized ones and choose Mercurial over Git for its simplicity of User Interface (UI).

FreeBSD

I tried to push FreeBSD to move over from CVS to Mercurial a few years ago. There were many discussions about it, I even wrote a paper about it (see the FreeBSD page for more details) but the temptation of keeping the same workflow with Subversion was too much and now the FreeBSD project uses Subversion for almost all repositories (although it keeps using Perforce for Google Summer of Code projects and user ones).