What methods do wikis use for merging concurrent edits?

Question

If two users edit the same wiki topic, what methods have been used in wikis (or in similar collaborative editing software) to merge the second user's edits with the first?

I'd like a solution that:

• doesn't require locking
• doesn't lose any additions to the page.
• It may add extra "boilerplate" text to indicate where differing changes were made.

(I'm interested in a solution that could be used to implement this uservoice idea for stack overflow.)

Answer 1

TWiki automatically merges Simultaneous Edits.

TWiki allows multiple simultaneous edits of the same topic, and then merges the different changes automatically. You probably won't even notice this happening unless there is a conflict that cannot be merged automatically. In this case, you may see TWiki inserting "change marks" into the text to highlight conflicts between your edits and another person's. These change marks are only used if you edit the same part of a topic as someone else, and they indicate what the text used to look like, what the other person's edits were, and what your edits were.

TWiki will warn if you attempt to edit a topic that someone else is editing. It will also warn if a merge was required during a save.

There was also some documentation from that feature being developed detailing how it would behave.

The basic principles I used in coding up the mergeing algorithm were:

1. If it's possible to merge without using conflict markers, do so.
2. If it's possible to merge using conflict markers, do so.
3. If it's not possible to merge, then the most recent checkin wins.

It's worth noting that TWiki has a similar feature to Stack Overflow for collapsing subsequent revisions by the same user within a certain time limit and this caused a bug when happening in conjunction with a merge.

1. User A edits topic
2. User A saves rev N
3. User B edits topic, picks up rev N
4. User A edits topic again, picks up rev N
5. User A saves changes; save sees that the change is within the ReplceIfEditiedWithin? window, so does not increment the rev number
6. User B saves, code sees that the rev number on disc has not changed since they started editing so doesn't detect a need to merge.

Also worth noting is that TWiki will warn the second user that the topic is being edited:

So I invented the concept of "leases". When a topic is edited, a lease is taken on the topic for a fixed period of time (default 1h). If someone else tries to edit, they are told that there is already a lease on the topic, but that doesn't stop them from editing. It isn't a lock, it's just a way of advising them. Mergeing is still the prime resolution mechanism; the lease is purely advisory. If a user - or a plugin - chooses to back away from a topic because someone has a lease out on it, well, that's up to the plugin.

The descriptive comment in TWiki.cfg is as follows:

   # 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.

note that the lease terminology is only for developers, not end users.

Answer 2

My experience with most Wiki software (e.g. MediaWiki) is that it tracks the version of the document you are editing. If the document changes during your time editing, your change is rejected and you are prompted to perform a manual merge.

Answer 3

You can write a "lock" in an other database table with the id of the user and the time and delete the "lock" (that isn't a real lock for those who do not understand) when the person save or after x minute.

This way, when someone try to edit and someone already doing it. A message can appear with the time remaining OR by just telling that someone else is currently editing the post.

Answer 4

Well, you could use a merging algorithm, like that used by source control software. You'd probably want to make it check for changes at the paragraph level, to help maintain readability.

If there was a potential conflict (e.g. two users editing the same paragraph), you would probably need to simply present both versions with boilerplate text and/or notify the second and subsequent submitters that the contents of their post may have changed from what they submitted.

Answer 5

Well now, I think that that would be a terrible, terrible idea. Let's be honest: merging is pretty dicey in code, and that at least has elements that might be isolated. Don't do this - human intelligence will always be better. Instead you are trying to replace it with an automatic solution that can result in output that is not sane, for no benefit.

Answer 6

In researching the TWiki answer I also stumbled across SynchroEdit which appears to be a SubEthaEdit style browser-based simultaneous multiuser editor. It looks like it may have been abandoned around September 2007, but there's source code available for download.

Answer 7

For documentation sake: DokuWiki places a 15 minutes lock on edited pages, which gets renewed whenever you preview your edits (ie. 15 minutes from your preview or edit start).