Какие методы используются вики для объединения одновременных правок?

Question

Если два пользователя редактируют одну и ту же тему вики, какие методы использовались в вики (или в аналогичном программном обеспечении для совместного редактирования) для объединения правок второго пользователя с первым?

Я бы хотел решение, которое:

• не требует блокировки
• не теряет дополнений на странице.
• Он может добавить дополнительный «шаблонный» текст, чтобы указать, где были сделаны отличающиеся изменения.

(меня интересует решение, которое можно было бы использовать для реализации этой идеи пользовательского голоса для переполнения стека.)

Answer 1

TWiki автоматически объединяет Одновременное редактирование .

TWiki допускает множественное одновременное редактирование одной и той же темы, а затем автоматически объединяет различные изменения. Вы, вероятно, даже не заметите этого, если не будет конфликта, который нельзя объединить автоматически. В этом случае вы можете увидеть, как TWiki вставляет «метки изменений» в текст, чтобы выделить конфликты между вашими правками и изменениями другого человека. Эти отметки об изменениях используются только в том случае, если вы редактируете ту же часть темы, что и кто-либо другой, и они указывают, как выглядел текст, каковы были правки другого человека и каковы были ваши правки.

TWiki предупредит, если вы попытаетесь отредактировать тему, которую редактирует кто-то другой. Он также предупредит, требуется ли объединение во время сохранения.

Была также некоторая документация от этой разрабатываемой функции, подробно описывающая, как она будет себя вести.

Основные принципы, которые я использовал при кодировании алгоритма слияния:

1. Если возможно объединение без использования маркеров конфликта, сделайте это.
2. Если возможно объединение с использованием маркеров конфликта, сделайте это.
3. Если слияние невозможно, выигрывает последний заезд.

Стоит отметить, что TWiki имеет функцию, аналогичную переполнению стека, для свертывания последующих ревизий одним и тем же пользователем в течение определенного промежутка времени, и это вызывало ошибку, когда происходило в связи с объединением .

1. Пользователь A редактирует тему
2. Пользователь A сохраняет обороты N
3. Пользователь B редактирует тему, поднимает обороты N
4. Пользователь A снова редактирует тему, поднимает обороты N
5. Пользователь A сохраняет изменения; сохранить видит, что изменение находится внутри ReplceIfEditiedWithin? окно, , поэтому не увеличивает число оборотов
6. Пользователь B сохраняет, код видит, что число оборотов на диске не изменилось, так как они начали редактировать , поэтому не обнаруживает необходимости слияния.

Также стоит отметить, что TWiki предупредит второго пользователя, что тема редактируется:

Так я и придумал понятие "аренда". Когда тема редактируется, по ней берется договор аренды на определенный период времени (по умолчанию 1 час). Если кто-то еще пытается отредактировать, ему говорят, что тема уже есть, но это не мешает редактированию. Это не замок, это просто способ дать им совет. Слияние по-прежнему является основным механизмом разрешения; аренда носит исключительно консультативный характер. Если пользователь - или плагин - отказывается от темы, потому что у кого-то есть аренда, ну, это плагин.

Описательный комментарий в TWiki.cfg выглядит следующим образом:

   # When a topic is edited, the user takes a "lease" on that topic.
   # If another user tries to also edit the topic while the lease
   # is still active, they will get a warning. The warning text will
   # be different depending on whether the lease has "expired" or
   # not i.e. if it was taken out more than LeaseLength seconds ago.

обратите внимание, что терминология аренды предназначена только для разработчиков, а не для конечных пользователей.

Answer 2

Мой опыт работы с большинством программ Wiki (например, MediaWiki) заключается в том, что он отслеживает версию документа, который вы редактируете. Если документ изменяется во время редактирования, ваше изменение отклоняется, и вам предлагается выполнить ручное объединение.

Answer 3

Для документации: DokuWiki устанавливает 15-минутную блокировку для отредактированных страниц, которая обновляется всякий раз, когда вы просматриваете свои правки (т. Е. 15 минут с момента предварительного просмотра или начала редактирования).

Answer 4

Исследуя ответ TWiki, я также наткнулся на SynchroEdit , который выглядит как браузерный одновременный многопользовательский редактор в стиле SubEthaEdit . Похоже, что он был заброшен в сентябре 2007 года, но есть исходный код, доступный для загрузки.

Answer 5

Ну, теперь я думаю, что это была бы ужасная, ужасная идея. Давайте будем честными: слияние в коде довольно рискованно, и в нем есть, по крайней мере, элементы, которые могут быть изолированными. Не делай этого - человеческий разум всегда будет лучше. Вместо этого вы пытаетесь заменить его на автоматическое решение, которое может привести к выводу, который не является нормальным, без какой-либо выгоды.

Answer 6

Ну, вы можете использовать алгоритм слияния, подобный тому, который используется программным обеспечением контроля версий. Вы, вероятно, захотите, чтобы он проверял изменения на уровне абзаца, чтобы обеспечить удобочитаемость.

Если существует потенциальный конфликт (например, два пользователя редактируют один и тот же абзац), вам, вероятно, нужно просто представить обе версии с шаблонным текстом и / или уведомить второго и последующих подателей, что содержание их сообщения могло измениться что они представили.

Answer 7

Вы можете написать «блокировку» в другой таблице базы данных с идентификатором пользователя и временем и удалить «блокировку» (это не настоящая блокировка для тех, кто не понимает), когда человек сохраняет через x минут.

Таким образом, когда кто-то пытается редактировать, а кто-то уже делает это. Сообщение может появиться с оставшимся временем ИЛИ, просто сообщив, что кто-то еще в данный момент редактирует сообщение.