Thoughts on Fossil

By David
/
First published 26th May 2016 (Last Modified 9th January 2021)

I've now been using fossil for about six months after I was unable to move my previous Rational Team Concert repository from one machine to another and it's time to do a small amount of reflection on that move.

First of all I ended up contributing to the fossil project to add the ability to add attachments to tech notes since I wanted to replicate RTC's ability to host build reports within the repository. There is a conflict in philosophy here in that most builds are ephemeral, but fossil regards its repository's history as inviolable (artifacts can be shunned in fossil, but that's a mechanism to prevent the artifacts from being displayed on the UI or distributed to peers of the repository (fossil is a distributed version control system rather than having a centralised server)). This, correctly, forced me to think about what I was preserving for builds and what shouldn't be in the repository even in my mental model (the general consensus in the fossil community is that build artifacts shouldn't be in the repository).

I concluded that I did want to keep the build reports and outputs for builds that were to be published on either tremlas.com or on Chris' waylandsgames.com. It has also led me to clean up the zips and general junk being created by my build process (I'm still a happy apache ant user since I've had no compelling reason to change what I was used when I worked on WebSphere Liberty.

I love how fast the web interface is! My primary copy of the repository is hosted on the same machine (an old Thinkpad A31p) which I use as its power consumption is similar to that of (now, for the time being, retired) NAS and it's i386 based, so I didn't have to figure how to compile fossil for a ARM-based linux.

I love that the repository file itself is just a single flat file - mine is currently just under 23 megabytes, most of which is the binary prereqs for my build enviroment (primarily ant-jshint.jar since writing JavaScript without the aid of any kind of checking tool is unwise.

The open source community for fossil is good, but somewhat small - it made several suggestions for improvements to my feature. However that small size meant it did take a while for the changes to get integrated into the trunk branch (which is the main development line).

Finally I'm very happy to have moved across to using fossil - it meets my version control requirements and then some.