"What if it is a new page, or there are no good revisions?" -- Anon
Some wikis place a "Revert this page" link at the bottom of each page. While this may make reverting vandalism easy, it also makes it easier for attackers to revert legitimate changes, as well as klutzes to do it accidentally. Reverts are much harder to tell apart than normal edits. Although you could explicitly flag reverts in RecentChanges as such, the reason for reverts aren't always clear.
Since you can assume that your PeerReviewers know how to revert a page, and if you don't want to make it easier for passing vandals to cause a nuisance, you may not want to put such a link at the bottom of each page. Besides, since there is already a simple and obvious way to revert pages, this "shortcut" link worsens your FeatureKarma.
Nonetheless, if you feel that reverting is a frequent and critical action, you may want to consider adding such a link, and then evaluate the results.
Most mature wikis have solved the potential EditConflict between steps 2 and 3. However, there is also a possible "user-side" conflict between steps 1 and 2:
This conflict is just as dangerous as standard EditConflicts, though much less common. It is important to design a wiki engine to rule it out.
Therefore, modify your wiki engine to warn the user if there is an edit between steps 1 and 2 of the three-step page-revert process. The easiest way to do this is to add a parameter to the URL of any old revision–viewing page (both viewing the rendered HTML and editing the wiki text) storing the revision of the page that was current at the time that URL was presented to the user.
Whatever links you provide the user, it is vital that any link taking the user away from the most recent view of the site be appropriately tagged. On MeatballWiki, for instance, that means pretty much every link off the action=history pages. Wikis that provide a 'view last revision' link from a detailed RecentChanges page would need to tag that, similarly.
The nice thing about including the current revision number in the URLs is that you only distract editors in the rare case that there has been a conflict. Visibly showing the current version of the page relies on the user checking if there's been a conflict every time they edit, when it's trivial to get the wiki engine to do that grunt work for them. Showing both revisions on RecentChanges has similar problems to the merging-with-markers approach to EditConflicts?: if two people come along and try to fix the user-side edit conflict, they can both collide and create another user-side edit conflict, requiring an out-of-line method of conflict-resolution when, frankly, the engine should be doing it for them.
A similar mechanism would help avoid the "user-side" edit conflict of "I look at the current revision of the page, then I edit it, but it's been changed in between". This conflict is less evil because it can be spotted by the eagle-eyed editor, but fixing it can only help improve visibility of changes to the site the editor should be aware of. -- ChrisPurcell
We just had the first user-side edit conflict I've ever seen ( will show it until the end of July 2006). The squashed edit (mine) didn't have anything lost, but it's interesting to know this isn't pure theory. -- ChrisPurcell