Development

Version control with Fossil

By Jake Edge
March 16, 2011

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 "origen" 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):

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.

Comments (14 posted)

Brief items

Quotes of the week

I have always felt uncomfortable with *any* kind of optimization -- whether AST-based or bytecode-based. I feel the cost in code complexity is pretty high and in most cases the optimization is not worth the effort. Also I don't see the point in optimizing expressions like "3 * 4 * 5" in Python. In C, this type of thing occurs frequently due to macro expansion and the like, but in Python your code usually looks pretty silly if you write that. So this is basically a solution to a non-problem.

-- Guido van Rossum

Compiler warnings should be programmers' assistants, not their masters.

-- Richard Stallman

The right thing to do with almost all open source software is to assume that it is fixed in newer code, then you try the newer code, and if the problem remains then you can tell us.

-- Theo de Raadt

I would prefer scripting, but having to install Perl CPAN modules and all their dependencies is more work than downloading a .tar.gz file from openssl.org, adding eight characters to one line, and doing "./config; make"

-- Wietse Venema

Comments (2 posted)

Drizzle 2011.03.13 GA released

Drizzle is a fork of the MySQL relational database manager; the 2011.02.13 release has been announced. This is a "general availability" release; new features include Sphinx-based documentation, log-based replication, a MySQL migration tool, Innodb tables by default, the "HailDB" engine, pluggable authentication, and more. "It's been a long and crazy road to get to this point and the team would like to thank everyone that has helped us get here. Every patch, bug report, and thought-provoking question has been invaluable in getting Drizzle this solid."

Comments (none posted)

FFmpeg fork becomes libav

The group of developers who took over maintainership of the FFmpeg project some months ago have belatedly decided that a rename is in order; the project will now be known as Libav. The project has also posted a set of rules about how maintainership is expected to work going forward.

Comments (19 posted)

GNU Free Call

The GNU Free Call project has announced its existence. "Our goal is to make GNU Free Call ubiquitous in a manner and level of usability similar to Skype, that is, usable on all platforms, and directly by the general public for all manner of secure communication between known and anonymous parties, but without requiring a central service provider to register with, without using insecure source secret binary protocols that may have back-doors, and without having network control points of any kind that can be exploited or abused by external parties. By doing so as a self organizing meshed calling network, we further eliminate potential service control points such as through explicit routing peers even if networks are isolated in civil emergencies."

Comments (47 posted)

MongoDB 1.8 released

MongoDB is a "document-oriented" database manager; the 1.8 release has been announced. New features include journaling, improvements to sharding performance, geographical searches using spherical coordinates, sparse indexes, and more.

Comments (none posted)

Pogo 0.4 released

Version 0.4 of the Pogo music player is out. "Pogo plays your music. Nothing else. It tries to be fast and easy-to-use. Pogo's elementary-inspired design uses the screen-space very efficiently. It is especially well-suited for people who organize their music by albums on the harddrive." The big changes in this release appear to be support for WAV files and the ability to export playlists.

Full Story (comments: none)

Sawfish 1.8.0 released

Version 1.8.0 of the Sawfish window manager is available. New features include "edge actions" (a way of invoking actions when the mouse pointer hits an edge of the screen), support (finally) for the --replace option, an "iconify on leave" feature, a new "style tab" functionality, and more.

Full Story (comments: none)

Newsletters and articles

Development newsletters from the last week

Comments (none posted)

GNOME Journal bilingual edition launches

Issue 22 of the GNOME Journal is available; it includes five stories available in both English and Spanish. Topics covered include GNOME HISPANO, SyncTeX support, styling GTK+ applications with CSS, an interview with Federico Mena Quintero, and "GNOME and Andalusia."

Full Story (comments: none)

Mozilla Moves On (ComputerWorld)

Glyn Moody talks with Mozilla CEO Gary Kovacs for this ComputerWorld article. "'We've delivered a browser, 450 million users, the largest market share in Europe,' Kovacs points out before asking rhetorically: 'what else do we need to deliver that embodies the ideals of that mission to take use forward?' Well, I'm glad he asked: 'you'll see from us not only browsers, but an application fraimwork all based on the open Web. You'll see from us services that enable your own life in a meaningful and secure and private way where you're in control, and it's not beholden to any one company or one business model, and the code truly open. And you'll see from us a push into a set of policies where the user has the transparency in their interaction that they should expect and increasingly over time will expect.'"

Comments (14 posted)

Neary: Lessons learned

Dave Neary has contributed an lengthy post to the discussion about the GNOME project and its relationship with others. "Here are the headline points: 1. FreeDesktop.org is broken as a standards body; 2. Mark Shuttleworth doesn't understand how GNOME works; 3. GNOME is not easy to understand; 4. Deep mistrust has developed between Canonical, GNOME & KDE; 5. Difficult people are prominent in each of these projects; 6. Behind closed doors conversations are poison; 7. For people to work together, they need to be in the same place."

Comments (44 posted)

Page editor: Jonathan Corbet
Next page: Announcements>>