By Zed A. Shaw

Why I Use Fossil

I like to use Fossil for my projects these days. It's a great little SCM that's easy to use, easy to deploy, and with one single binary works on every platform you can imagine. What's kind of interesting though is proponents of git, bazaar, and mercurial like to insult my choice for various reasons. Usually their reasons for not liking fossil are either very shallow, or the exact same reasons people who liked SVN said they didn't want to use git/bazaar/mercurial.

For example, people who use git like to say fossil is weird. Fossil's actually pretty normal compared to git. The commands make sense, there's help, and it's simple so each thing does one thing. Git users however will avoid fossil because it's not like git, and don't want to learn anything new, yet when git came out those same people kept saying learning git was like learning C. It's good for you!

Well, what if learning fossil is good for you? Hell, I think you should know all the SCMs you can and be able to switch between them. You might not like it, and I complain all the time I have to commit a merge in mercurial, but I know how to use them anyway.

Another complaint people have about fossil is that it looks like crap. I'm sorry, but if you're comparing fossil to github or bitbucket then that's an unfair comparison. Github and bitbucket are hosted services that get paid money and have been designed to support many projects at one domain used by many people. Fossil is fairly new, and while it supports most of the features or more that github and bitbucket do, it's designed by programmers to be used by other programmers. It's not that great of a design, but the UI is pretty easy to use and gets the job done.

So why do I use fossil? It's simply about Yak shaving and trying to reduce the amount of bullshit in between me and getting a project out the door. With fossil, I can crank out a whole project web site, with built-in wiki, ticket tracking, user management, and source control with one command. Not only that, but everyone else on the project gets the exact same setup and all of the data is equally shared on every computer I've ran into.

This is the reason I've been able to crank out projects lately. Before if I wanted to publish my stuff I had two choices:

  1. Give my data to services like github, bitbucket, launchpad and then deal with all the whiners who don't like whatever I chose like somehow that makes their tribe inferior.
  2. Setup all the gear I need for each project. Trac, maybe another wiki, probably a database, separate web server domains, nginx configs, and then manage all that for each project.

With option #1 I'm stuck having all my project's data on someone else's server, and may eventually be forced to pay them for hosting if I decide to do something non-opensource or if I get too large. On most of these services it just takes one jerk pushing a few huge files into my source before my project is killed, or a bad economy and suddenly the service is gone. If you don't believe me, ask all those Etherpad or DabbleDB users whether they'll trust a service again. In the age of the "acqhire purchase" putting my source code on some other server just isn't a good move.

With option #2 I'm yak shaving server administration rather than coding. Installing trac, wiki, user management, and other systems for multiple domains sucks hard. Very hard. Hell trac for multiple projects sucks. If you add to this the hosting costs of these systems, where each one is a 30-120M python process per project or site, you start to see how it isn't viable for small projects, or even medium ones. Currently I spend about $1 for each project and invest almost no time maintaining them. Using a system like Trac (which is not easier to use BTW) or any wikis, or any blog systems, is just not economically feasible.

Enter Fossil

The advantage of fossil is it removes all the barriers I have to publishing a project. If you want to set up your first drop of a project it's this:

fossil serve

That's all. You now have your new project, including a wiki, ticket tracking, timelines, revision shunning, user management, CSS/html tweaking, and everything you need to get started ready to go. Not only that, but it's the same on Windows, Linux, NetBSD, FreeBSD, and OSX. Pretty much anywhere that sqlite3 can build, fossil can run.

Now, to host this on my server what do I do?

  1. Copy a proxy stanza I have for nginx.
  2. Create a user for the site, like say mongreldev.
  3. Add fossil http /home/mongreldev/fossils/mongrel2.fossil command to inet or xinetd.
  4. Put the .fossil sqlite3 in the right place.

That's it, and with this I get a nice security bonus that fossil will chroot and then drop priv to the user that owns taht fossil repo (in this case mongreldev). If it gets hacked, then they just have access to that one user not the whole site.

Remember though that this isn't the process of just setting up the equivalent to Trac. This is the four steps I need to setup the equivalent of:

  1. Nginx
  2. Trac and maybe MoinMoin if you needed.
  3. hg browse, or whatever git's using that week
  4. User admin for those.
  5. HTTP access to git or hg.
  6. Fully annotated .zip downloads.
  7. RSS feeds of all changes.
  8. For a full domain.
  9. With custom looks, CSS, and logos for each project.
  10. Fully secured.

I run this off a very tiny VM slice as well, and because fossil is written in C, even running it on inetd uses no RAM and is fast. My fossil setups have survived simultaneous hits from HackerNews, Reddit, and Slashdot without falling down. That's with no tuning, no caching, and an inted setup.

That's really all there is to it. I don't think fossil is really superior to the others, as I'm sure they all have their strengths and weaknesses. It's just if I'm going to create projects fast and get them out, not having to deal the system administration yak shaving is great. I want to code, not baby site a Trac, hand out ssh keys, or figure out how to get hg to safely serve a timeline.

For me, the ease with which fossil lets me publish far outweighs the risk of people not wanting to help on my projects because they don't like it. In fact, I'd say that if fossil's default CSS makes you not want to contribute to my project, then I probably wouldn't want to write code with you. It's a sign that you have a problem objectively evaluating software and you'd probably bring the completely wrong aesthetic to my code anyway.