I’ve been using Fossil as my SCM for quite a few years now and it has served me well. It replaced my aging Trac (which I’ve now really retired in the recent server move … it didn’t move) + GIT setup. There is nothing inherently wrong with it and upstream are quite quick to resolve any issues. So lets start with a list of Fossil plus points, in no particular order:

  • BSD license.
  • One binary, easy installation, very low maintainence cost.
  • Integrated CGI web front end.
  • Integrated Wiki, Tickets- which are also distributed.
  • Sane command line UI.
  • Stores everything in a SQLite database.
  • Repository is not joined to the checkout, supports different checkout from the same cloned repository.
  • I have had a Fossil commit bit - my change allows a near perfect Fossil to git bridge.

And naturally, after many years of use, there are some negative points:

  • The ticketing system is very basic and has no email support- you’re expected to use each tickets RSS feed, but this is not clear.
  • It’s not extendable.
  • It’s possible for an admin in the upstream repo to wipe out parts or the whole of your cloned repo.
  • It’s not social.

That’s actually a very small list of negative points. It shows that Fossil is a great product, with a great team behind it. Let’s address these these negatives in more detail though.

The ticketing system is is poor

Yes, the tickets are distributed, but that’s the only good point. The UI to progress the ticket needs a lot of work and is not intuitive to use. Tickets don’t support markdown. It’s not clear to the end user that the only feedback they get is a RSS feed. My initial attempt to fix this was about 3 years ago but was met with silence. I could try and improve this by creating a fossil branch just to add RSS icons to the ticket UI.

Fossil is not extendable

This isn’t actually that bad, what it does have works well enough (aside from the ticketing). And to be fair, there is a 3rd party library to extend fossil but it doesn’t seem to be used by anything I can find. However, based on recent experiences at my day job (where I don’t use Fossil), code reviews are turning out to be quite critical and the tools we were using suck. Well, Fossil doesn’t have any code review feature nor any easy way of hooking it into an automated build system for continuous integration So we’re left reviewing changes via pastebin where links expire or diffs via email. Now diffs via email have been standard on many open source projects, and still are in many. Most of the time I can read them fine, but sometimes they are hard to review in an email. Sometimes I end up using a code review tool, loading the dhcpcd source code, copy and paste the diff into it, reviewing and then copying my review comments back into the email. This is hardly ideal and quite time consuming.

Fossil history can be wiped out

Fossil has an ability to delete anything from your cloned repo - it’s called shunning. While this is an awesome feature for corporations (I work for one, I understand the problems and wish my day job had this feature), but equally I believe it’s entirely un-suitable for open source use. This is my PC, it contains my contributions to a project which could wipe out my copy of said project and published contributions. History, gone. Now, it’s entirely likely that this will never happen, I like to believe in the good in people, but the possibilty remains someone could push the button. OK, there’s a bit more to it than that- the default fossil setting is to auto-sync the shun list. However, the code is disabled for auto-sync (ie sync on commit) but is enabled for the manual pull/push commands. While that removes the item from your checkout (if it’s there), it won’t actually remove it from the repository itself until the repository is rebuilt, which is sometimes forced on you when upgrading fossil. Yes, this is probably a knee-jerk reaction to a none-issue, but it still grates. This is also a reason why I love to self host and would never consider having GitHub or similar being the one sole place where I publish my work. I have always, and always will do, self host.

Fossil is not social

By it’s very nature, you can’t contribue to the club unless you’re in the club- at least not using just Fossil. It’s designed (from my perspective anyway) to be a distributed CVS/SVN + wiki + tickets. By this, I mean there is one master repository everyone clones from and pushes to. This makes it impossible to have my own branch outside of the main repo and publish it to others (equivalent of GIT Fork and Pull). It can also be argued that this is a good thing because it encourages people to work together and just like the prior point, this is a good feature for corporate setups. But equally sometimes someone needs to maintain a patchset unsuitable for upstream for valid reasons. This is rare, but it has happened. And I hate losing users for any reason. Could they have a branch they maintain in my repo? Quite possibly, but Fossil’s security isn’t that granular AFAIK and I would dislike someone messing around in the other branches. Maybe that’s anti-social of me, but equally no-one has ever asked for commit access to my repos either.

EDIT: Dr Richard Hipp pointed out privately that this is The Cathedral and the Bazaar. Fossil is the pre-eminent solution for The Cathedral, while others are more suited to the Bazaar.

In summary

Taking the above into account, I can no longer justify the use of Fossil in my Open Source projects. For other projects, Fossil is still an awesome tool if that’s all you need.