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
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
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
autosync to be the proper default (in the "4.0 Workflow" section of the Fossil
The [author] finds that projects run more smoothly in autosync mode since
autosync helps to prevent pointless forking and merge and helps keeps all
collaborators working on exactly the same code rather than on their own
personal forks of the code. In the author's view, manual-merge mode should
be reserved for disconnected operation.
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.
to post comments)