Трехстороннее объединение: Первое, на что следует обратить внимание, это то, что большинство одновременных правок, особенно в более длинных документах, относятся к различным разделам текста. В результате, отметив, какие ревизии приобрели пользователи A и B, мы можем выполнить трехстороннее слияние, как описано Биллом Ритчером из Guiffy Software . Трехстороннее объединение может идентифицировать, где изменения были сделаны из оригинала, и, если они не конфликтуют, оно может незаметно объединить оба редактирования в новую статью. В идеале, на этом этапе выполните объединение и покажите Пользователю B новый документ, чтобы он мог выбрать для его дальнейшей доработки.
Разрешение столкновения:
Это оставляет вас в сценарии, когда оба редактора редактировали один и тот же раздел. В этом случае объедините все остальное и предложите текст трех версий пользователю B, то есть включите оригинал, с версией пользователя A в текстовом поле или пользователем B. Этот выбор зависит от того, считаете ли вы, что по умолчанию следует принимать последние версии (пользователь просто нажимает кнопку Сохранить, чтобы сохранить свою версию), или заставлять редактора дважды редактировать, чтобы внести свои изменения (они должны повторно применить свои изменения к редактору А). версия раздела).
Такое трехстороннее объединение позволяет избежать блокировок, с которыми очень трудно хорошо справиться в Интернете (как долго вы позволяете им иметь блокировку?), И сценарий обострения «вы, возможно, захотите посмотреть снова» , который хорошо работает только для ответов в стиле форума. Он также сохраняет стиль пост-ответа в сети.
Если вы хотите немного повысить Ajax, динамически 3-стороннее объединение версии пользователя A с версией пользователя B во время ее редактирования и уведомление об этом. Это было бы впечатляюще.