![[Home]](http://meatballwiki.org/meatball.gif)
EditConflict
MeatballWiki | RecentChanges | Random Page | Indices | CategoriesWhen two people A and B view the current page revision X, and both start to edit the page, then A will save revision X+1, and B will experience an edit conflict.
There are several ways of dealing with this:
Winner takes it all
The latest edit wins. In this case, the changes by A will be lost. One solution might be a warning to show when B saves: "The page was changed 42 seconds ago by A. Please check whether your overwrote any changes." This solution is probably the easiest to understand for users.
Examples: none
Don't overwrite new revisions
Use a time-stamp on the edit page, and when saving a revision, make sure that nobody has saved a new revision in the meantime. In this case, B will be told that the original page has been modified, and that his changes cannot be saved. Usually this is accompanied by some sort of dialog that allows B to compare his revision and the new revision, and submit a manual merger. This is surprising and complicated for users, but it is easy to code.
The time taken to integrate changes can act as a kind of DelayAction in flame wars and the like. When there is tension amongst contributors, little edit conflicts are suddenly perceived as intentional edits ("Oh my god, you deleted my comments! You ****!"). Also, it's better if B waits until A has completely finished commenting, because B should take A's edits into account.
- A case in point was a recent spat on another wiki. Someone made a quick, long and emotional reply to one of my comments. I didn't appreciate his comment at all, and started writing an equally angry reply. Fortunately, before I could post, he toned down his message, and the "don't overwrite new revisions" policy on that wiki permitted me to cool down. A 'winner takes all' approach would probably have escalated the flamewar.
Others feel that the desire to avoid edit conflicts (which are painful) lead people to write quickly and with little thought.
Examples: UseMod, WikiPedia, WikkiTikkiTavi
Use an AutomaticMerge to reconcile revisions
Use a time-stamp on the edit page, and in case of conflict, merge the new revision with the edited page. Command line tools such as merge and diff3 algorithmically merge two revisions based on their common ancestor (version control systems such as CVS use this).
Sometimes conflicts cannot be solved intelligently, for instance if A and B both alter overlapping text. Merge tools can add specific conflict markers to the result, which makes conflict resolution easier for the editor. There are nevertheless still several choices:
- Present two edit boxes as in "Don't overwrite new revisions" above
- Overwrite the older version as in "Winner takes all" above, maybe with a message
- Insert merge result including conflict markers, maybe with a message
The last option, in particular, allow the merging work to be done by whoever happens past, as and when. Unfortunately, it can also lead to conflict cycles, as people repeatedly try to fix previous conflicts and, of course, conflict again. The only recourse then is an out-of-line solution, a sub-optimal conclusion.
Lock the original
Another option is to lock the page as soon as A decides to edit the page. This requires a certain time-out period, since A might very well decide to abandon his edit. After the lock timed out, we have the same situation as before. If the time-out period elapsed, the wiki might just disallow saving the changes. In combination with a time-stamp, the wiki might just disallow saving the change if somebody else created a new page in the mean time. At this point, all the solutions mentioned above might be used, but if the time-out period is long enough, there is often no need to solve this problem. A long time-out period might be a problem for sites where a lot of users will abandon edits.
This behaviour may be exploitable by bot-using spammers: post spam, then repeatedly lock the page to prevent anyone reverting it.
Examples: MoinMoin, TwikiClone
if an edit conflict occurs, IMHO it would be better if the two text areas with the other version and my version were placed directly after another. Currently there is the summary field, save/preview buttons, username stuff between them. Therefore it is difficult to get both of these text areas together on the screen to compare them. Feel free to move this suggestions to a maybe more appropriate page. -- MarkusLude
- Even better would be a visual merging system. -- ChrisPurcell
Does any wiki allow forking of pages when edit conflicts occur? The last person that submits creates a fork, and is notified. The wiki page displays a list of revisions for the page, until someone takes action. Eg. delete or rename one of the page revisions or merge them. It could attempt an AutomaticMerge but if fails, still have the fork to fallback to. -- JaredWilliams
CategoryWikiTechnology