4 ms·
> The only case Automerge cannot handle automatically, because there is no well-defined resolution, is when users concurrently update the same property in the s
by mabbo 5y ago
> The only case Automerge cannot handle automatically, because there is no well-defined resolution, is when users concurrently update the same property in the same object (or, similarly, the same index in the same list). In this case, Automerge arbitrarily picks one of the concurrently written values as the "winner"
I think using the term 'arbitrarily' makes this seem less useful than it is. When I initially read it, I scoffed at this library.
What's critical is that it consistently and deterministically picks the same winner, so all copies of the data structure, once the same updates are applied, have a consistent view. That's so important and the authors do a disservice by not being explicit about this here.
- WolfOliver 5y agoIf I'm not mistaken, the solution is strong eventual consistent. While one change is picked randomly, it is the same on each node.
- NuclearFishin 5y agoI really like the idea of this library and I've bookmarked it for future use, but following on from your point, it does feel disingenuous to make this promise in the introduction: > (Different from git: no merge conflicts to resolve!) As you've pointed out, there _can_ be merge conflicts, they're just resolved arbitrarily. In theory, git could do this too but obviously nobody would use it then! CRDTs themselves are inherently conflict-free, but if the problem you're solving is not, implementing via CRDTs is not the silver bullet you're looking for.