Fossil SCM — Version Control System

Analysis of Fossil

João Duarte Pinto
4 min readMay 5, 2021

What is?

Fossil is a distributed version control system, like Git, Mercurial and Bazaar.

Has a Built-in Web Interface, that runs in a instance of Fossil. The Web Interface is themeable, extensible and intuitive and has:

  • Ticketing;
  • Bug tracking;
  • Wiki;
  • On-line documentation;
  • Technical notes;
  • Forum;
  • Chatroom;
  • Timelines;
  • Full text search;
  • Graphs of revision and branching history;
  • File and version lists and differences;
  • Historical change data;
  • Add and remove tags on check-ins;
  • Move check-ins between branches;
  • Revise check-in comments;
  • Manage user credentials and access permissions;
  • And more…

Is a All-in-one single self-contained, stand-alone executable.

Fossil is Self-host Friendly, most projects can be hosted on a virtual private server or even on a Raspberry Pi.

Supports Autosync mode, in which automatically keeps your changes in synchronization with your co-workers through the use of a central server.

Is Robust and Reliable, transactions are atomic, even if interrupted by a power loss or system crash. Automatic self-checks verify that all aspects of the repository are consistent prior to each commit.

The last, but not the least: it’s Free and Open-Source!

Differences Between Fossil And Git

A short summary of the differences between Git and Fossil:

Adapted from: Fossil/Fossil Versus Git

Featureful

”Fossil adds an integrated wiki, ticketing & bug tracking, embedded documentation, technical notes, a web forum, and a chat service, all within a single web UI, protected by a fine-grained role-based access control system.”

”Fossil can do operations over all local repo clones and check-out directories with a single command. For example, Fossil lets you say “fossil all sync” on a laptop prior to taking it off the network hosting those repos.”

”Fossil is small, complete, and self-contained. If you clone Git’s self-hosting repository, you get just Git’s source code. If you clone Fossil’s self-hosting repository, you get the entire Fossil website — source code, documentation, ticket history, and so forth.”

”For developers who choose to self-host projects (rather than using a 3rd-party service such as GitHub) Fossil is much easier to set up, since the stand-alone Fossil executable together with a 2-line CGI script suffice to instantiate a full-featured developer website.”

Self Contained

”Fossil is a single self-contained stand-alone executable which by default depends only on common platform libraries.”

Development Organization

The Fossil development mode is Cathedral style. Fossil places a lot of emphasis on synchronizing all developers, so that everyone has a real vision of what is happening in the project.

What you should have done vs. What you actually did

”Git puts a lot of emphasis on maintaining a “clean” check-in history. Extraneous and experimental branches by individual developers often never make it into the main repository. Branches may be rebased before being pushed to make it appear as if development had been linear, or “squashed” to make it appear that multiple commits were made as a single commit.”

”Fossil, in contrast, puts more emphasis on recording exactly what happened, including all of the messy errors, dead-ends, experimental branches, and so forth. One might argue that this makes the history of a Fossil project “messy,” but another point of view is that this makes the history “accurate.” In actual practice, the superior reporting tools available in Fossil mean that the added “mess” is not a factor.

As an example, when several branches have been used, if they are always part of the same story line, there is no distinction as to what actually happened.

Test Before Commit

”One of the things that falls out of Git’s default separation of commit from push is that there are several Git sub-commands that jump straight to the commit step before a change could possibly be tested. Fossil, by contrast, makes the equivalent change to the local working check-out only, requiring a separate check-in step to commit the change. This design difference falls naturally out of Fossil’s default-enabled autosync feature and its philosophy of not offering history rewriting features.”

--

--