The Fossil SCM

See also: fossil.wanderinghorse.net

The Fossil SCM, a distributed version control system (DVCS), is, since Christmas break of 2007, my source control system of choice. It's orders of magnitude easier to use, and more convenient, than my arch-nemesis git.

Until chronic RSI effectively removed me from the Open Source world in late 2014, i was a frequent contributor to the core Fossil SCM project, and am the architect and primary implementor of its JSON API. (i have since returned to active contribution, but chronic RSI puts a severe limit on it.) Fossil is single-handedly responsible for my return to the C programming language, which i had abandoned for 15+ years in favor of script languages and C++. To the best of my knowledge, i was the first person, other than Fossil's father, D. Richard Hipp (of sqlite fame), to host a Fossil-specific internet [sub]domain: fossil.wanderinghorse.net is where i host all of my public version-controlled repositories (mostly software, but this website is also managed in fossil). Fossil's ability to run as a CGI-hosted process makes it absolutely trivial to host on even the least expensive hosting services (any hoster which supports compiling and running CGI apps suffices). For users with their own servers, Fossil can also run as a standalone server process. Fossil has a built-in wiki system, a ticket-tracking system, and various real-time reports (that feature was also initially my baby, but it has since been improved upon by several contributors).

Why git has become so widely-used, i'll never quite understand. It's fussy, utterly misanthropic, difficult to administer, and it literally allows users to rewrite the history of source-controlled files, including the ability to delete older versions of a source-controlled tree. That's not only philosophically wrong, but flat-out braindead. i've literally lost more data in/via git than in/via any other software in my 30+ years of working with computers. Fossil, on the other hand, is easy to use, braindeadedly simple to administer and host online, and has literally never lost a single byte of data for anyone (the only reported cases of corruption of a Fossil repository involved bad media, against which no SCM can protect (keep backups - something fossil makes trivially easy to do)). The features of git which many git proponents claim are "must-haves" are actually features of 3rd-party hosters like github, not git itself. i opine that without github, git would never have been able to become nearly as widespread as it has, simply because doing anything truly useful with it is a huge pain the butt. Fossil, by comparison, is a dream to use. When googling for "how to do X in git", one is likely to find at least 3 or 4 seemingly authoritative answers, only one of which (at most) will actually work. The others, worst-case, may do nothing at all or may cause data loss. True story: i once had one of the maintainers of libgit sit at my workstation for a full half an hour to get my local git clone back into working order after i'd followed "instructions" on StackOverflow about how to simply commit my changes. Whereas git makes even the simplest things more complex than they should be, fossil makes even the most complex things simple.

Unlike git, fossil is designed to be used by small, relatively tight-knit teams. It does not scale well (or at all) to the size of projects like the Linux Kernel, LibreOffice, and similar massive trees. Projects of that scale are where git shines (for a given value of "shine"). Fossil is, however, truly great at managing "smaller" source trees with no more than a couple dozen developers. By "smaller" i don't mean "toy trees", but real-world trees with a scope limited to a single app, library, or a small collection of those. Fossil was initially implemented for a single purpose: to host the sqlite source tree. Because Fossil is itself based on sqlite, those two projects have a recursive relationship. Being based on sqlite gives fossil the world's single most robust file format, with complete "ACID" compliance and transaction support. A change to a fossil database is either 100% complete or 0% complete, but is never somewhere in between like a git transaction may be (e.g. due to an ill-timed system outage or C-level signal). Apropos database: all content for a fossil repository is stored in a single sqlite database file. To back it up, simply copy that file somewhere safe. Every copy/clone of a repository contains the entire history of the managed project, so each copy acts as a full backup of the project.

Anyway... if you manage source control, especially if you have "personal projects" you'd like to put into source control, fossil is worth considering. For small/personal projects, there is no easier, more feature-rich, more robust option out there. Give fossil a try for a day or two and you'll likely be convinced.