[garmaine]

This is the same underlying theory as the “operational semantics” that is used by Google docs to merge out-of-order changes by simultaneous editors and resolve into a single consistent shared global state. So take that as a proof of principle that it works for more complex structured information.

[dan-robertson]

The underlying theory is not really the same. The practice is also not the same.

Google doesn’t need a different representation where all push outs exist because they rely on a centralised server, low latency, and arbitrarily choosing how to resolve conflicts. In a DVCS, you can rely on none of these.

[garmaine]

In not sure if Google still used operational semantics for Docs, but that is not how operational semantics works. The theory allows you to take two quite different stacks of changes and interleave them in a consistent way. It does not rely on low latency or a centralized server. The choice of arbitrary tie breaker vs. manual resolution in the case of conflicts is an application domain choice not mandated by the theory. Obviously in the case of Docs the tie breaker makes more sense.

[dan-robertson]

I think this is getting off topic as Anu/Pijul is not doing operational transformations (I assume this is what you meant when you wrote operational semantics).

I still claim that the reason OT works well with google docs is that it can rely on a centralised server, low latency and tie breaking.

Tie breaking means one doesn’t need to worry about representations of conflicts (and allowing changes to merge in sound ways) which is in some sense the main thing pijul does.

Low latency means that users are able to cope with the tie breaking rules doing the wrong thing

A centralised server means that there is less need for the merges to work in the sound way that pijul aims to make them work.

Therefore I put it to you that google docs is neither an example of the same theory that pijul is based on not evidence that OT would work for some kind of well-behaved structure-aware DVCS.