4 ms·
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
by LockAndLol 6y ago
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.
- audience_mem 6y agohttps://sqlite.org/lang_vacuum.html https://sqlite.org/lang_vacuum.html
- LockAndLol 6y agoThank you. So my intuition was correct about deletions creating non-contiguous data. I wonder how often VACUUM is run by fossil.
- mmcdermott 6y agoI'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 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=tip https://www.fossil-scm.org/xfer/file?name=src/import.c&ci=ti...).