How does a wiki handle multiple simultaneous edits?

Question

This has always lingered in the back of my mind, so I figure I might as well go ahead and ask.

How does a wiki handle multiple edits on the same content?

Here's a simplistic example of what I'm asking. Let's say that a page has the following content:

I'm a page!

And now let's say that two go to edit that page. Each person adds a sentence:

Person one:

I'm a page!
I'm a second sentence in the same page!

Person two:

I'm a page!
I'm a second sentence!

Imagine each person's second sentence being an equally relevant but different fact about the topic of the page that each person wanted to add in.

Now let's say that person one submits their changes before person two does, but person two doesn't even get a chance to see the changes that person one made. Does person two's changes overwrite those of person one when he finally goes to submit?

Is there a diff / merge algorithm that could be used for this?

Answer 1

There could be a transactional-mechanism that uses locking to prevent a file from being edited twice. (http://en.wikipedia.org/wiki/File_locking)

Answer 2

It depends on the flavor of wiki. There are many dozens or hundreds of wiki clones. Typically the second user will get a "this page has been edited by another user" error message, and then they must go reload the page and redo their edits.

A wiki certainly could merge the two edits together the same way a version control system like Subversion does. If you're familiar with the UNIX patch command, it would involve diffing user 2's edit and generating a patch which is then applied. The patch may or may not succeed; in your example there'd be a merge conflict, and so it'd be back to the old "this page has been edited by another user, you lose" error message.

Answer 3

I believe Wikipedia uses a fairly simple diff/merge algorithm, similar to how most source code control software does it.

In the example you gave, it would raise a merge conflict error, because there's no way for it to know which line should come first in the final markup. The second person to save their changes would be presented with a merge error page where they have to choose how to resolve the conflict.

Keep in mind, though, that wikipedia is on the high-end of the concurrent users scale. For the majority of wikis, it would probably be acceptable to use a very simple "last save wins" algorithm, where the second person's edits simply overwrites the first person's. With the addition of history, it should be easy for the first person to spot that their changes have been overwritten and add them back again.

I believe this solution is what Stack Overflow uses. SO has an additional feature where an Ajax call is used to notify the editor if someone else comes in and modifies the page before they're finished.

Answer 4

How does a wiki handle multiple simultaneous edits?

That depends on the implementation of the wiki.

Is there a diff / merge algorithm that could be used for this?

Any merge algorithm that meets your requirements will do.

Generally it depends on the behavior you like the wiki to have. For example, you may choose to implement your wiki in such a way that Person Two's change won't be committed as the article has been modified and Person Two is working on an outdated base copy. Potentially Person Two would enter something completely different if he/she was aware of the changes. In that case you may choose to not allow committing Person Two's changes. This can be achieved with the transactional mechanism Kurt Du Bois mentions in his answer.

Another option would be to implement an approach that always allows saving the wiki article. In this case you may lose the changes of Person One while in the first approach you would lose the changes of Person Two.

A third approach would be to present both articles side-by-side in a merge window. I am not aware of a wiki that supports this. If it did I was wondering what would happen if co-incidentally three (or more) people are modifying the same document.

So if you are using a wiki, I'd suggest to keep edits small.

If you are implementing a wiki, you have a choice of how you want your wiki system to behave.