The reasons I use fossil are that it's the only version control I have found that I can get working through the VERY annoying MS firewalls at work.. (albeit through an ntlm proxy) and I just love single .exe applications!

With one of my several hats on, I'm in a small team using git. Another team member just checked some stuff into trunk that should have been on a branch. Nothing else had happened since, so in fossil I would have just edited that commit and put it on a new branch. In git that can't actually be done without danger once other people have pulled, so I had to create a new commit rolling back the changes, then branch and cherry pick the earlier changes, then figure out how to make my new branch shared instead of private. Just want to say thanks for fossil making my life easier on most of my projects, and being able to move commits to another branch after the fact and shared-by-default branches are good features. Also not having a misanthropic command line interface.

Sometime in late 2007 I came across a link to fossil on sqlite.org. It was a good thing I bookmarked it, because I was never able to find the link again (it might have been in a bug report or something). The reasons I first took a close look at it were (A) it stemmed from the sqlite project, which I've held in high regards for years (e.g. I wrote JavaScript bindings for it: http://spiderape.sourceforge.net/plugins/sqlite/), and (B) it could run as a CGI. That second point might seem a bit archaic, but in practice CGI is the only way most hosted sites can set up a shared source repository with multiple user IDs. (i'm not about to give out my only account password or SSH key for my hosted sites, no matter how much I trust the other developers, and none of my hosters allow me to run standalone servers or add Apache modules.)

So I tried it out. The thing which bugged me most about it was having to type "commit" or "com" instead of "ci" for checking in (as is custom in all other systems I've used), despite the fact that fossil uses "ci" as a filter in things like the timeline view. Looking back now, I have used fossil for about about 95% of my work in the past year (dead link), in over 15 source trees, and I now get tripped up when I have to use svn or cvs.

So, having got over typing "fossil com -m ...", here's why I love it so much...

Point #1: CGI

Again, this sounds archaic, but fossil has allowed me to share source trees which I cannot justifiably host in other projects I work on (they don't belong to those projects), which I cannot host in google code (because google code doesn't allow/recognize Public Domain as a license, and I refuse to relicense just to accommodate them), and for which SourceForge is overkill (and way too slow). With fossil I can create a new repo, have it installed on my hoster (http://fossil.wanderinghorse.net), and be commiting code to it within 5 minutes.

Point #2: Wiki

I hate wikis. I really do. Always have. They all have a different syntax and the content tends to get really disorganized really quickly. Their nature makes it difficult to reorganize them without replacing old pages with lots of "has been moved to [TheNewPage]" links. I'm one of those "code for tomorrow" coders (i.e., code such that it'll be easy to reorganize/refactor later). I like to document the same way, and wikis make that problematic. Then again, no documentation system is really good in that regard.

That said, fossil has made me love having a centralized, common documentation platform. Whereas I used to document everything in the API docs (header files) and often include an ODT file for a library manual, fossil has become my preferred platform for non-API documentation because it's just so easy to do. No matter where I am, I can log in and write (I write a lot). The added ability to export my wiki pages, edit them in xemacs, and re-import them just makes it nicer, as I can tweak as much as I want without ending up with 10 "updated wiki page SoAndSo" messages in the commit log.

Point #3: running a server locally

Fossil runs not only as a CGI, but as a server. I don't WANT to host my own server (and don't have the rights to on my hosters). I hate server-side maintenance (a hate born from years of administering systems). But the server has other uses. When working on the wiki, bug reports, etc., the local server is *the* way to do it. It's blazingly fast and much more productive. When you're done, just run "fossil push" and everything's synced.

Point #4: the single-file repository

Having all controlled content inside a single container file has been a godsend when it comes to backups and copying/moving a repository. There are no access or file ownership issues, which are often problematic with other server-side systems (at least on the initial install). For about 5 years I administered a CVS repo for a company for, and every time someone added a directory to the (huge and dynamic) source tree I had to log in and "chmod 4775" the directory before others could commit to it. Fossil's model inherently eliminates that type of problem, and I'm a *huge* fan of solutions which inherently (that is, due to their very nature) avoid certain foreseeable problems. The single-file repository model's flexibility would seem to become more problematic for huge repos (a few hundred MB+) with many users with differing levels of access (e.g. OpenOffice, Firefox, or the Linux Kernel), but 99.9% of projects never reach anywhere near that size or complexity.

In summary:

I remember my first reaction to fossil being, "this will be an excellent solution for small projects (like the dozens we've all got sitting on our hard drives but which don't justify the hassle of version control)." A year of daily use in over 15 source trees has confirmed that, and I continue to heartily recommend fossil to other developers I know who also have their own collection of "unhosted" pet projects.