fossil-scm

The Fossil Source Control Manager (SCM) has not yet gained the notoriety of other distributed SCMs such as Mercurial or Git. Given the amount of available choices (centralized vs distributed, GUI-based vs command line, open-source vs proprietary, etc.) it shouldn't be unexpected to ask: "why would one want to try yet another SCM? After all, it's enough work already having to get acquainted with one SCM." You pick one yourself, or you have your team tell you to use one, and you stick with it for a very long time and try to live with its idiosyncrasies. The project's website addresses other criticisms such as "why another one?" or "why not that other tool?", etc. To this the author and contributors essentially respond that this tool is made to solve a specific set of requirements that concern the authors. This means that requests for new features tend to be filtered by the authors' intent of consistency of the tool and tendency to "keep it simple enough".

The project's homepage does a good job at summarizing the strong points of this DSCM. As far as I am concerned, what motivates me to use it for small personal projects, as well as within a team of two or three people for commercial development, are the simple installation (it's just one executable, typically under 4MB if you keep debug symbols!), availability in multiple platforms (Windows, Linux, and also Mac, BSD), a wiki and a simple ticket system, its own self-hosting web server which can be run from console (or interfaced through CGI with an existing web server, including hosting sites such as ChiselApp), and the possibility to carry both the repository (a single SQLite file) and the executable on a USB disk. Given the small footprint, Fossil makes for a considerable choice in systems with more modest resources compared to normal systems.

Coming from a Subversion background, Fossil's handling of branching gave me confidence to try it out in a constructive way; being able to run it locally allowed me to test it and gain a minimum proficiency to use it in actual software projects, where I kept my codebase in Fossil and committed to Subversion for the users who were still adhering to it from the project's start. I stopped worrying about breaking the SVN revisions with inadequate branching and I could try different ideas and switch between branches before committing to the trunk.

New users might be discouraged by the strong reliance on the console, especially in environments that already have IDE integration (Subversion, Git). For those on Windows there are a few attempts at providing a GUI for Fossil, but so far there's still missing a "TortoiseFossil" with the same integration as the remaining integrations on Windows; although one such namesake project exists, at the time of this writing it's still in early development. Integration with many popular IDEs is lacking, therefore forcing the user to keep a console handy, but for those used to working from the console I expect that it shouldn't be discouraging.

From the onset I found that Fossil to be less daunting than Git for setup and use. It didn't take long for me to become accustomed to it and integrate it on my workflow. Naturally, others will disagree and point out that another choice of SCM is superior, or that Trac provides a richer feature set. But I'd reply that this tool's simplicity of use and modest requirements provide for most of the use that I've come to expect of a SCM. While I don't presume to say that Fossil will fit everyone's expectations, as well as other choices won't do for everyone either, I recommend that you give it a try for a small enough project that should make use of what are, in my viewpoint, Fossil's strong points -- small footprint, integrated web server, wiki and ticket system, containing the repository on a single SQLite file and simple deployment (a single executable file).

I personally use Fossil because it's amazingly efficient. It's one simple program with no dependencies, I can put it anywhere and use it, needs no libraries or admin privileges.

It even has a built-in web server, which I can use to set up a collaboration platform quickly almost anywhere, with a few changes to Nginx config, or even without a front-end, as Fossil can handle HTTP directly. It's written with C and is so fast, that I can set up as many projects as I want and see zero footprint on server resources.

Generally, I think that Fossil is what a good program should be. Not bloated, written in another new language with another runtime library for every function, using hundreds of files because you can always add more RAM, but small, fast and easy on resources, because that's enough.