Weird new (to Twitter) paper with and . The title basically tells the whole story:
Merge What You Can, Fork What You Can’t:
Managing Data Integrity in Local-First Software
riffle.systems/papoc22.pdf
In a few more words...
Conversation
Nice idea! So you can delay merging conflicts, but can you change how they eventually resolve? I.e. cherry pick the winner. That is the key property of version control that so far I haven't seen done in CRDTs.
2
5
Yes, that’s exactly right. Ideally the app exposes some tools for figuring out what the difference is and then helping you patch things up.
In the meantime, if everyone’s seen the same events then at least you all agree on what the different branches are.
2
6
In the case of branching, then now I need to be sure I am making changes to the right branch, right? Isn't that too much to ask from the regular user? Or are changes somehow applied to all branches? (helpful, but dangerous?).
1
1
The user definitely needs to be aware of branching; I don’t see a way around that. I do think that this is a serious design challenge that needs to be addressed (in addition to the technical implementation challenges).
1
2
I don’t think it’s hopeless though. For example, if your changes don’t depend on the particulars of one branch, it should be easy to “rebase” them onto another branch.
Thanks. I guess that may strongly depend on the shape of the data being worked on, some will be easier to make sense of (and being able to preserve integrity) than others.
1
1
Yes, absolutely! I think a trick is to really lean hard on the "merge what you can" side: the app developer should be quite thoughtful abut defining conflicts (and needs tools to do that), so the user doesn't see conflicts that they wouldn't "intend".
2