3 ms·
> 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.
by pmeunier 5y ago
> 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).
- samatman 5y agoGeneric backend is wonderful news! 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.