Congrats on the beta release! I've been following along for awhile with great interest, looking forward to picking out a couple repos and shadowing git with pijul now that it's beta.
Since you mentioned sanakirja, I'd like to ask: the obvious (to me) reason to build it, rather than use SQLite, is easy ABI compatibility with the rest of the project through Rust. Are there other architectural reasons it's particularly suited to pijul?
I ask because I already store as much as I can in SQLite databases, and am moving to patchsets and changesets for certain kinds of document-oriented data management. Storing pijul's artifacts in that same system would be a natural fit for my application, so I wonder how closely tied together the two codebases are on a practical level.
> Are there other architectural reasons it's particularly suited to pijul?
Yes, I originally wrote it because I wanted to fork tables without copying any byte. This is how channels (similar to Git branches) are implemented in Pijul.
> I wonder how closely tied together the two codebases are on a practical level.
Pijul can use a generic backend, although in practice only variants of Sanakirja have been implemented. Sanakirja is generic enough to handle different workflows, although large values aren't implemented yet (they aren't hard to implement, I just never needed them and nobody else did it).
As it happens SQLite added some of the machinery from fossil for no-copy tables and changesets as an optional extension. I mention this because it gives me hope that I might cobble something efficient together in SQLite, I could offer a few reasons I'm glad Sanakirja exists aside from pijul and the advantage to your project of being able to tweak both sides of the system is compelling.
Congratulations again on the beta. Doing hard and basic work for years is to be commended.
Since you mentioned sanakirja, I'd like to ask: the obvious (to me) reason to build it, rather than use SQLite, is easy ABI compatibility with the rest of the project through Rust. Are there other architectural reasons it's particularly suited to pijul?
I ask because I already store as much as I can in SQLite databases, and am moving to patchsets and changesets for certain kinds of document-oriented data management. Storing pijul's artifacts in that same system would be a natural fit for my application, so I wonder how closely tied together the two codebases are on a practical level.