I've been fiddling with Fossil (https://fossil-scm.org) lately and the fact that it includes Wiki, forum and bug lists in the core source control project is looking better and better with all of this.

I checked it out and am kind of on the fence about one file = one repo - especially SQLite.

It's mostly because I remember filesystems from my university time and trying to implement one in a file myself. Continuously adding data is fine, but when you remove data either you leave a "hole" in the file and have to keep track of the "empty" blocks, or you shift everything to fill the hole. Off-by-one errors corrupt files.

Those are all resolved problems for filesystems, but additionally, I learned the hard way (performance) that SQLite wasn't good as a production db. The situation here is different of course (db access isn't very frequent), but I can't quite shake it.

Maybe I'll dig into the internals to understand what kind of optimisations they made. The wiki and bug-tracking are definitely a plus though.

Thank you. So my intuition was correct about deletions creating non-contiguous data. I wonder how often VACUUM is run by fossil.

I'm no expert on the code, but vacuum comes up a lot when grepping the source. For example, it looks like it always runs vacuum after a remote clone (clone_cmd in https://www.fossil-scm.org/xfer/file?name=src/clone.c&ci=tip) and after importing from another SCM (import_cmd in https://www.fossil-scm.org/xfer/file?name=src/import.c&ci=ti...).

Fossil is great, highly recommended.