Effectively Simultaneous Changes due to Network Partition

Whereas in the case of simultaneous modification due to transmission delay, we could effectively backup with a minimum of confusion to the user (so long as we inform them why we've done so), we cannot do so in the case of simultaneous modification due to network partitioning.

If only single lines have been modified, there is no real problem, as the later change will be asserted, and although this may not be what the user whose change just got replaced actually wants, at least the document ends up in a consistent state.

However, if the user making the earlier modification adds any new lines (particularly if they do so by inserting a line-break into the middle of a line), then there is a potential for the document to end up in an inconsistent state. We shall show later that we can detect simultaneous insertion, thus to maintain internal consistency, we should treat the splitting of a line (by adding a linebreak to the middle of an existing line) as deletion of the old line, plus insertion of two new lines.

It is also possible to keep a local copy of the state of any line we have modified at the time we last modified it in order to be able to re-assert the state if the conflict resolution was not what we actually wanted. However, it is always possible to envisage ways to defeat such a scheme if it were to be performed automatically, so such a re-assertion should only be performed with explicit consent from the user for each step.

We hope that these mechanisms will not be often called upon, but choosing a line as our minimum unit means that there will always be occasions when such mechanisms are called upon. How effective they are depends largely upon how well it is communicated to the user what has happened, and what options they have to deal with it.