<< Linux ptrace and jmap | Home | How to do notifications after a JTA commit >>

Goodbye Subversion, hello Fossil

Today I made my final commit to the Subversion repository that I have been using for my main coding work for the past 8 years. That repository was created on October 30, 2004, and it has been through two server changes, two changes of corporate ownership, and an unknown number of software upgrades since then. There was actually a prehistoric CVS repository on yet another server where everything started in the summer of 2003, but the change history from CVS was never imported to Subversion. I forget exactly why, but I think there was some problem with the conversion script, so only the final CVS revision was imported.

My reason for abandoning Subversion is much the same as for many other people: there are distributed version control systems available today that are much more powerful than a centralized system. This is useful even when working alone, if you are like me and do development work on more than one computer.

To replace Subversion I settled on Fossil, written by Richard Hipp (who is coincidentally the author of the most widely deployed database software in the world, SQLite).

Here are the things I like about Fossil:
  • It's lightweight and very easy to install, and comes with a built-in web GUI, issue tracking system, and wiki.
  • All changes are transactional, through the use of a database engine with a proven track record.
  • And of course, it's a distributed repository. Like any distributed version control system this gives us:
    • No mandatory single point of failure.
    • No round-trip to the server is needed to view the change log or for using blame/annotate features.
    • Enables new powerful features like bisect.
    • Allows offline work.
There are some things I liked about Subversion that I will probably miss:
  • Having global revision numbers is much more pleasant than those horrible UUIDs. But this is only possible due to having a centralized design, unfortunately.
  • The possibility to check out only a part of the whole source tree.
  • External modules, although the concept has some quirks.
  • WebDAV integration was cool, but I have to confess I didn't use it much.
Why not Git instead of Fossil, considering the enormous popularity of Git? Well, I have been briefly exposed to Git used for "read-only" purposes, i.e. downloading and tracking code from various open source projects, and I have only had pleasant experiences with that. But when I tried to actually host my own code with Git, I quickly got frustrated. For that kind of use, Git has a much longer learning curve than Fossil. Also when looking at the differences in design, Git seems to be more targeted towards code maintainers in huge projects with many contributors, rather than towards developers. I also found it harder to approach an understanding of the Git design. In part this is probably due to feature creep and lack of distinction between conceptual model and implementation detail. This could of course be alleviated by the use of tools like EasyGit, but why bother if Fossil already has everything I need (including web hosting, issue tracker, and GUI) from the outset, all bundled in a single executable?




Add a comment Send a TrackBack