Low Ceremony Revision Control

Revision control is generally a good thing, even for single-developer projects. It protects you from yourself. It makes it easy to have a history of changes of a project. But all too often, it requires a lot of extra overhead to manage and use.

We used CVS for years for project work, and despite its many quirks (especially when dealing with code edited on both Windows and Unix systems) it served us well. But it required a fair bit of management to keep it happy, and creating a brand new repository required actions be taken on the one machine that acted as our central server. As that machine aged, we began to be concerned about the inevitable effort involved when we eventually would be required to move that server.

So we shopped for a new solution. By that time, CVS was itself seen as quirky and elderly; and support it on Windows was spotty. We quickly discovered that the newfangled distributed version control systems had matured to the point where it made sense to abandon our dependence on a single server.

We looked at least briefly at all the usual candidates after narrowing our search to only open source tools with official support for Windows among other platforms. For a variety of reasons, that meant that we glanced at Mercurial (aka Hg), Git, Bazaar, among others. Unfortunately although each of those named have strong followings, they are all (or were when we were shopping) either weak on Windows or outright hostile to Windows. Further, they all lean towards being complex tools with complicated UIs oriented to serving the needs of very large projects. Git, for instance, was born explicitly to provide source control for the Linux kernel.

Finding the Fossil

Then we found Fossil. Fossil was created when the sources to SQLite outgrew their previous home in CVS. So right from the outset, it was clear that its design had been informed by the known issues with using CVS across a variety of platforms over a mid-sized source kit.

Low Ceremony

One of fossil’s strong advantages is that it was designed for “low ceremony”. You don’t have to do much configuration of anything, the database file itself can be kept locally, and it mostly just stays out of the way.

I use it on a handful of projects that are mostly single-principle-developer and am quite attached to it. Because it introduces so little repository management obligations, it is easy to adopt when the project is new. By making branches easy to create and merge, it makes it really easy to move experimental work and new features into branches where changes can be committed early and often without endangering a trunk (primary line of development) version that is known to always build and run.

One key feature is that the physical storage of a project’s repository is a single SQLite database file. The file format is fully documented, as are the database schema used within SQLite. The developers are concerned that the storage underneath it be absolutely bulletproof, and their use of SQLite helps achieve that goal.

Small but Friendly Community

It has a small user community partially because it hasn’t had much overt marketing or evangelism. But that community makes up for its lack of marketing by being very responsive on its mailing list.

Development is open source, and it generally builds without pain on any platform supporting a relatively recent C compiler. The core developer team are generally quick to respond to bug reports, and they generally welcome public discussion of new features and possible implementations.

Used on Bigger Projects

Fossil’s own source code is stored in a fossil repository. There are perhaps ten active users that commit changes to it regularly.

Fossil is also the version control standing behind SQLite, so it is both a user of SQLite for its database file, as well as an important supporting tool for SQLite’s implementation. Fossil generally incorporates the latest version of SQLite, and is used in part as a deliberate use case for the database as well as a way to catch any new SQLite bugs early through aggressive adoption and use.

Distributed is Safer

Fossil is designed as a distributed version control system. Each user’s machine holds at least one complete copy of a project’s repository. Assuming the network is available, it is easy to arrange for changes made at a user’s machine to be synchronized with a remote copy as they are committed locally.

Naturally, changes made remotely will also be brought back to the user’s local copy, and any conflicting changes will be brought to the user’s attention.

Out of the box, each repository stores the URL of one other with which it is synchronized automatically, but it is also possible to synchronize with any number of external clones through command line options and scheduled tasks or cron jobs.

Even for a single user, taking advantage of the ease of replication of a repository is a good way to provide an offsite backup. Park clones of your repositories on a second machine with a minimal amount of CGI configuration and you can autosynch your work and have a live backup. Put that machine in a friend’s house or at an inexpensive webhost and you have an offsite backup.

But Wait, There’s More

In addition to rock-stable revision control, fossil also supports a wiki, a issue or ticket tracker, a web server, and the ability to display static content from checked in documents. You can even download a ZIP or tarball of the source code from any revision.

See the fossil homepage for a good starting point to its use. Any repository can be viewed via the built-in web interface which allows access to the timeline, ticket system, wiki, and project settings. It also can be used to view documents that are checked into the repository. In fact, all links to pages at the fossil web site are being served by a copy of fossil.

There is a decent book in draft form that walks through the process of using fossil for common tasks in a reasonably sized project.

The 4 is also maintained by fossil, and its web interface is served by a copy of fossil as well. All the SQLite repositories and the fossil repository are kept synchronized among several geographically separated servers by cron jobs that do periodic fossil sync commands.

One easy way to get a hold of a repository with a rich history to play around with is to clone the source to fossil itself. To do this, put a copy of the fossil executable in your PATH, then in an empty folder somewhere say

C:...>fossil  clone  http://www.fossil-scm.org/  fossil.fossil
C:...>mkdir src
C:...>cd src
C:...>fossil open ../fossil.fossil

You are now standing in an open fossil repository containing the complete source code and revision history of fossil. With GCC, awk, and zlib available, you should be able to build it from source. (On Windows, it is easiest to build with MinGW from an MSYS bash prompt in my experience.)

You can periodically do fossil update to keep your clone current, and I recommend you try fossil ui to see the full power of the web interface with administrative access to your clone.