Tag name：fossil

Thoughts on Fossil

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.

running fossil as a daemon process

This is just a note to myself in case I need it 🙂

To run fossil as a daemon process on Ubuntu. I did the following:

  1. Created a fossil user and home directory and gave it a copy of the fossil executable and the website fossil file
  2. Created a fossil/etc/init.d/fossil file
  3. Issued 
    sudo /etc/init.d/fossil start
  4. Run sudo update-rc.d fossil defaults to get the init.d script run at system start.

This /etc/init.d/fossil runs multiple fossils.

Moving from RTC to fossil

First published 14th December 2015 (Last Modified 9th January 2021)

I am a fan of IBM's Rational Team Concert, but have reluctantly decided that I need to move from it to something much easier on the operations side. My specific problem is that the Ubuntu machine on which I run the RTC server needs a clean reinstall1. Having tried (on my laptop that also has Ubuntu installed) to use my backup of the repository2 to get a working clone of the RTC system has proved a LOT harder that I would like, I ended investigating alternatives.

Fossil is my selected alternative, at least for the time being. The pro's and con's (at least as compared with RTC) are:

Pro's

  • Install is easy (I'd go as far as trivial) - fossil is a single executable (with executables for Windows and Linux (also Mac, though I don't have any of those at this time))
  • Includes a problem tracking system as well as a source control system (also a wiki)
  • The repository is a single file, yet is still a SQL database (fossil uses SQLite)
  • Its mental model for development is not that dissimilar to RTC
  • Builtin web server for admin and browse capabilities (OK, so you have to run the executable to get the server running...)
  • Moving from RTC will allow me to use an up to date eclipse - not that the current version I'm using is broken!

Con's

  • No integration with eclipse - this one is a shame, but my website and plugins are small enough that I can handle running a commit command to put my changes into the repository
  • No included build support (though fossil can generate a rss feed). I did investigate getting jenkins running, but since there's just me and I already had one-step build running, I've (for the time being at least) decided I can manage to run a manual build instead
  • The lack of build support means there's no immediately obvious way to publish build results - this is next on my investigation list (I suspect using either a wiki page, or technotes might be a substitute, but I'm worried about wanting attachments in some form - I guess that's another con for the moment.

As you can probably guess I do consider this to be a shame, but I don't want to spend lots of time attempting to set up RTC on a reinstalled machine so that it's the same as before

Footnotes

  1. Somehow my kernel and the /boot are not in sync (I think the /boot partition that's being mounted is NOT the one that grub is using at boot time, and since I'm also having to manually select the upstart kernel (the standard kernel locks up in the G15 keyboard handler that I installed) AND the size of the /boot partition is tiny I need to do a reinstall to get to a clean system ↩
  2. OK, I admit it, I didn't prove that I had a backup by attempting the restore on a different machine earlier ↩