It's a shame they don't use a SQLite database for version control. I know it's probably the least efficient way to store code changes but it would bring a whole new level to bootstrapping processes. Each code change would be inserted into the db by the code produced by the prior change.
I know it's probably the least efficient way to store code changes
Not at all. Fossil's own repository (sqlite) database currently (as of this moment) has an overall compression ratio of 101:1, packing a total of 6.7GB of data into 66.5mb.
Comments
It's a shame they don't use a SQLite database for version control. I know it's probably the least efficient way to store code changes but it would bring a whole new level to bootstrapping processes. Each code change would be inserted into the db by the code produced by the prior change.
It would be exciting as it is stable.
Fossil does use SQLite as its storage engine.
See point 7 on the "about fossil" page:
https://fossil-scm.org/home/doc/trunk/www/index.wiki
You do realise that both Fossil and SQLite have the same creator?
Not at all. Fossil's own repository (sqlite) database currently (as of this moment) has an overall compression ratio of 101:1, packing a total of 6.7GB of data into 66.5mb.