Version control with Fossil

Within a year or so after the nearly simultaneous debuts of Git, Mercurial, and Bazaar in 2005, another distributed version control system (DVCS) was introduced called Fossil. Unlike the other three, Fossil has maintained a much lower profile. A recent announcement that Tcl/Tk would be moving from the SourceForge CVS repositories to Fossil raised that profile a bit. So, what is Fossil and what distinguishes it from the other choices in the DVCS space?

Fossil was created by D. Richard Hipp, who also created SQLite, and its first release was in 2006. Since that time, a number of projects have started using Fossil for source code management, including, unsurprisingly, SQLite, but also the Mongrel2 web server, the PRITLOG blog system, and now Tcl/Tk. Others are undoubtedly using it as well, but as the project's "Questions and Criticism" page notes, "fossil does not yet have the massive user base of git or mercurial".

To start with, Fossil is more than just a DVCS, it also includes bug tracking, wiki, and blog, all of which are set up for distributed operation. It is, in some ways, an integrated project management system like Trac, but it has a different set of features that are meant to satisfy Hipp's requirements. He worked on an earlier project (CVSTrac) that inspired Trac, but Fossil is clearly an effort to scratch his particular set of itches. It would seem that other projects are starting to find that it works for them as well.

One of the main differences from Trac, and one that will be very familiar to DVCS users, is the idea of disconnected operation. But, beyond the usual ability to edit and commit code that a DVCS provides, Fossil allows editing bug tickets or changing the wiki locally, then synchronizing those changes to other repositories at a later time. Disconnected operation is the "killer feature" that Fossil provides over Trac, at least for Hipp's purposes.

But Fossil has some other characteristics that will be attractive to some. It is a single monolithic binary (fossil) that handles all of the source code management tasks, without using any external programs (like diff or patch). That binary also handles web requests for source code browsing, bug ticket handling, and repository synchronization. Because it is standalone, it can be easily installed in its own chroot() environment to isolate it from the rest of the system. Monolithic may give the wrong impression, however, as the binary is only around 800K in size.

All of the data is stored in SQLite (again, no surprise there) in what Hipp calls an enduring file format: "A fossil repository is intended to be readable, searchable, and extensible by people not yet born." The current implementation uses deltas and zlib-compressed blobs stored in the SQLite database. Like other DVCS programs, Fossil uses SHA1 hashes to identify the "artifacts" that are stored in the repository.

Unlike other DVCSs, Fossil has a repository that is stored separately from the working tree, rather than as hidden directories like the default for Git or Mercurial. Also unlike those systems, Fossil's repository is just a single SQLite file that can be easily copied or moved as needed. A working directory is associated with a specific Fossil repository (in a specific location), in some ways like the "origin" concept in Git.

Typically, each developer has their own repository on their local machine with one or more local source trees (or working directories) associated with it. Repositories can be synced with each other via HTTP. There are two different modes of operation for syncing, "manual-merge" mode (which is the way that Git and Mercurial work) or "autosync" mode (which is similar to how CVS and Subversion (SVN) work). One of the interesting aspects of Fossil is that it supports both of these modes.

In autosync mode, a commit essentially also does a push to the server where the code was cloned from or the one that was most recently used to sync. Then one uses the "update" command to pull the most recent changes into the local repository and to merge them into the local source tree. Manual-merge mode just decouples the commit from push, and update from pull so that users need to do each of those parts separately (and indeed can do those parts separately). The documentation says that the author believes autosync to be the proper default (in the "4.0 Workflow" section of the Fossil Concepts page):

Since many projects using DVCS are often running in disconnected mode (at least conceptually), it makes sense that Git, Mercurial, and others only support the manual-merge style. Fossil would seem to be targeted more at smaller projects, with fewer developers, possibly all working for the same company on a single project. In some ways, it is targeted at replacing CVS or SVN with a distributed tool while more-or-less preserving the workflow that those tools provide.

One thing that cannot be said about Fossil is that it lacks for documentation. There is voluminous documentation of Fossil including its design philosophy, a technical overview, a Quick Start Guide, a comparison to Git, and more, all found linked from the main Fossil project page. There is even an 87-page User Manual available in both PDF and Fossil repository format. There should be very few barriers to getting going with Fossil.

In some ways, Fossil sits in between the VCS and DVCS worlds. For projects that like the idea of keeping their bugs and wiki together with their code (and documentation), Fossil is definitely worth a look.