3 ms·

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

I've been fiddling with Fossil (https://fossil-scm.org 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.

cookiecaper 6y ago
Fossil is great, highly recommended.
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 ago
  https://sqlite.org/lang_vacuum.html https://sqlite.org/lang_vacuum.html
  - LockAndLol 6y ago
    Thank you. So my intuition was correct about deletions creating non-contiguous data. I wonder how often VACUUM is run by fossil.
    - mmcdermott 6y ago
      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 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...).

cookiecaper 6y ago

Fossil is great, highly recommended.

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 ago
https://sqlite.org/lang_vacuum.html https://sqlite.org/lang_vacuum.html
- LockAndLol 6y ago
  Thank you. So my intuition was correct about deletions creating non-contiguous data. I wonder how often VACUUM is run by fossil.
  - mmcdermott 6y ago
    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 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...).