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

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 2

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.