今天尝试了这个实验：为一个谷歌文档打开了两个离线编辑器。在一个，我加粗了第一个词。第二次，我删了。不管我先打开哪个客户端，这个词总是会被删除。
首先，为什么会这样——我对运营转型的理解是排序很重要？在两个人分别输入“a”和“b”的简单示例中，如果服务器首先收到“a”，它将通过将第二个人的“b”事件转换为“传递一个空格”来强制输出“ab” ，然后添加 b" 事件，反之亦然。
其次，如果订购无关紧要，那么 Google Docs 选择在删除方面犯错是否有技术原因？或者原因很大程度上对用户来说很简单？
这是（5年后我知道）正在发生的事情的图形解释（实际上是@osma描述的，但图形解释了）：
当您在 GDocs 中加粗一个字符串时，您实际上是将字符串包装到一个容器中，可能是<strong></strong>它们可能使用任何其他语法。为简单起见，我们只说加粗字符串只需要在单词开头有一个“+”。这样文本“lorem ipsum”就会变成lorem +ipsum而不是lorem <something>ipsum<something>
Alice 和 Bob 都有起始文本“Lorem ipsum”
然后鲍勃删除“ipsum”。请注意，他发送给服务器的是变更集retain(6), delete(5)。变更集本质上是一个补丁，它的结构很可能基于这个库。
Alice 将“ipsum”加粗（添加“+”）。请注意，她发送的是变更集retain(6), insert(+), retain(5)
两个变更集现在都正在传送到对这些变更集一无所知的服务器。
假设最坏的情况：Bob 的包裹先到，然后这个词会被删除。（另一种情况很明显）。
当 Alice 的包裹到达时，它只会在文本中添加一个“+”，因为她发送的只是一个 changeset。
两个文本都是向客户端广播的变更集。这是第一个。
这是第二个。
在将这些变更集修补到原始文本中之后，您最终会得到“Lorem +”。这个符号稍后会被一个常见的 HTML 清理过程删除，该过程会消除任何带有格式的标签<tag></tag>，
要测试此演示，请访问：http: //operational-transformation.github.io/visualization.html。在那里，您可以在发送/接收文本和包裹时玩它们。
这不是在删除方面犯错的问题。
如果两个客户端都具有平等有效但不同版本的真相，Google Docs 必须选择支持一个版本，或者强制用户解决冲突，这本质上是复杂且难以解释的。
因此，Google Docs 的“真相”是文档的一致性，而不是意图的辨别。最好通过破坏信息更容易地实现一致性——一种熵倾向。
所有这一切基本上都是我的半哲学BS虽然......
OT 不会尝试辨别意图，它会按产生一致结果的顺序应用转换。当您将这两项更改应用到文档时，应用它们的顺序无关紧要。
“第一秒”->“第一秒”->“第一”
“第一秒”->“第一”->“第一”
在第二个流中，对长度为零的字符串执行粗体操作。
如果在其中一个文档中将第二个单词斜体，这与您得到的结果完全相同：无论转换顺序如何，最终结果都是“第一秒”。删除转换也不例外。