There are two ways to view the moving of a chunk of text:
Deletion and then re-insertion is wasteful of bandwidth and causes extra state to have to be held (and sent) for the deleted lines. We are sure however that no-one can have already changed the new lines, assuming deletion is not overriden by modification, that the original lines cannot be re-asserted.
Modifying the context information of the bordering lines and just re-sending this information has the possible advantage that someone modifying the moved text in its old position due to temporary partitioning sees her changes reflected in the new positioning after the partitioning has been resolved. However, it is possible that one or more of the bordering lines are modified in a partitioned site after the move has occurred, and that the resolution of the partition then undoes or partially undoes the move, resulting in a block where no-one knows the correct line ordering.
Allowing the possible situation of no-one knowing the correct line ordering is extremely undesirable, and so we treat moving as deletion and subsequent re-insertion, despite the additional overheads this entails.
Next: Garbage Collection and Check-pointing Up: Limitations of the Data Previous: Deletion of Lines of Jon CROWCROFT