You may not have heard the name D. Richard Hipp, but you’ve used his software: SQLite is his creation, and it’s everywhere. SQLite is an impressive piece of work, but it’s not alone. Along the way, Hipp also wrote LEMON, his own parser generator for parsing SQL in SQLite.
And now he has his own distributed source control, Fossil, which hosts the SQLite development stream. Fossil is interesting because it’s also a distributed wiki and bug tracker, kind of like Trac meets Mercurial or something. As with all of his work, the Fossil documentation is very clear about the design principles and internals, again, very impressive.
SQLite’s documentation includes a detailed page about how it is tested, including how its coverage is measured. Needless to say, it is well measured: 100% condition coverage! The description there of the use of C macros to enhance measurement is a good example of how macros can be extremely useful in building complex software, and makes me wish for something with similar capabilities in Python.
I admire Hipp’s output, but I worry that it might be somewhat insular. SQLite obviously has great acceptance, but what will happen to Fossil? It has a huge uphill climb to get users, what with Git and Mercurial slugging it out, and a dozen others competing for attention.
It’s the age-old dilemma about using the best technology or the most widely accepted. In this case, I don’t even know if Fossil is better than the alternatives. At this point it doesn’t have the critical mass that would even move it from the Curiosities category to the Look Into It list.