Today I was introduced to CRDT based version control through a post to Manyana: A Coherent Vision For The Future Of Version Control | Lobsters about a “new” version control tool “Manyana”:
From the comments of this I found Pijul. I find this approach to version control very interesting but as an obvious newcomer, I am not well versed in the intricacies. I was hoping for some input from people who already knew about this and were involved, is this an ‘accidental’ copy of Pijul? Are there ideas here that are different?
Obviously it is much less mature, it is barely a python script currently. But I guess I just wanted more experienced input!
The difficulty of writing a version control system is in no way even remotely related to what the blog post describes. In particular, if you want to handle conflicts, resolutions must be part of the basic operations of the datastructure, or else you won’t be able to rebase them. In that blog post, there is one set of operations (add/delete), and a mere possibility of adding a separate set for handling conflicts, which the author admits doesn’t exist yet.
Properly handling conflicts using a single set of operations (for both “usual” ones and conflict-related ops), is several orders of magnitude harder than what the author describes. Part of the theoretical foundations of Pijul rely on a mathematical proof that the structure we use is the simplest possible that handles conflicts well, and that rather abstract structure required a huge effort in low-level system programming. The ability to do both isn’t common. Concretely, Pijul is based on maths (categories, graphs, complexity), yet required its own key-value store (the Sanakirja project) in order to implement branches. That key-value store also ended up being the fastest known on-disk key-value store (Pijul - Rethinking Sanakirja).
The main contribution of that blog post seems to be related to showing conflicts to the user in a nicer way than Git, which is certainly an important feature. However, the main problem with Git has nothing to do with that: the main problem with Git is that rebasing and merging are heuristics based on content similarity, with no model of conflict resolution.
I don’t think rediscovering Pijul accidentally is even possible. I know how incredibly hard it is to get these things right. The fact that no bibliography at all is mentioned in the blog post isn’t a very good sign of seriousness: indeed, a basic rule of research is that you can’t go very far without understanding what others have worked on. In particular, there have been multiple attempts at doing “CRDTs for version control” (I forget the names right now, but also I’m not writing a blog post), Mercurial is innovating way faster than Git, Pijul has been around for 10 years…
4 Likes
Yes, aplogies, i didnt mean to minimise over a decade of work. I guess i meant ‘rediscovery’ in the sense that the author clearly was searching for a tool like Pijul because of similar motivating frustrations and obviously didn’t search hard eniugh to find it so assumed it didn’t exist.
Thank you for your long response, it largely echoes what i figured when i wrote the question. But obviously as a new incomer, i was curious what more experienced people in the area of research thought.
I have since spent more time reading the theory of Pijul and watching talks and I’m quite excited to dive in!
2 Likes