Editing Conflicts
This page discusses edit conflicts, and how to deal with them. To understand what an edit conflict is, consider the following situation:
- Andy clicks "Edit this page" on a page.
- Chris clicks "Edit this page" on the same page.
- Andy finishes her edits and clicks "Save page". The page is saved with Andy's version.
- Chris finishes his edits and clicks "Save page". Chris gets an "edit conflict" page.
Layout of the edit conflict page
At the top, you will see Andy's version of the whole page, even if Chris is doing section editing.
At the bottom, you will see the text Chris was going to submit. This will be Chris's version of the page, if he edited the entire page, or Chris's version of the section he edited, if he was editing just one section.
In the middle is a diff of the two pieces of text. For the section, Chris is editing it shows Chris's changes and Andy's possible changes, except what both have changed in the same way. For the other sections, it shows the full new text as if all that text was added.
Chris can edit the upper text and press Save. In the case Chris was doing section editing, this will be interpreted as the new version of the section, hence produce duplication of the other sections, unless Chris deletes them before saving. (This seems to be a bug.) The best solution in this case is to save your new text (e.g., to the Clipboard), cancel out, then try again.
When pressing Save and the system is slow, you may be able to make another edit and press Save again before the system responds. This gives an edit conflict with oneself. In this case, the upper text may be the old version instead of the one involving the first edit, i.e. the system notices the earlier change but has not processed it yet. A moment later. while you are looking at the edit conflict page, the first change is carried out in the background, and the upper text no longer is the current one. Hence, the diff shows the combined edit, and in the case of section editing, like before, the "addition" of the other sections.
Resolving an edit conflict
If Chris only made small changes, and Andy made large changes, he may choose to work from Andy's version, and re-merge his changes in. Chris might choose to add some text like "via edit conflict" to warn Andy and others that he had to do this - Andy can then peer review his merging for accuracy.
If Chris made large changes, and Andy made small changes, he may choose to work from his version. One option is for Chris to copy the bottom text into the top text (or just copy over the one section of the top text, if Chris was section editing), with an appropriate edit summary (eg "via edit conflict, will remerge"). Then Chris can view the page history, determine Andy's changes, and re-apply them to his version, in a separate edit.
If both Andy and Chris made large changes, matters become complicated, and Andy and Chris just have to do the best they can. For example, if both Andy and Chris simultaneously add a large section of text on the same subject, then it may be best for Chris to submit his changes, and then for Andy and Chris to both have a look at the two versions and decide between themselves which version is better.
Chris should not just post his changes over the top of Andy's. We assume good faith - mistakes are occasionally made, and newcomers may not understand the edit conflict window. However, Chris must not routinely ignore edit conflicts. It is absolutely not acceptable for Chris to overwrite Andy out of laziness. We encourage you to double-check their merges by using the diff feature found on an article’s History page.
Logical edit conflicts
(This is a conflict between editors that is undetectable by the mechanism that decides whether to give the "edit conflict" message.)
Some people edit by copying the source text into a text editor, making lots of changes (reorganizing, adding new content, etc...), and then, when they're done, pasting the whole thing back onto Chickipedia as a single (new) edit. If someone else has made changes in the meantime these changes would get lost in the paste back. People who edit in this manner should either:
- paste only into the same edit box that was originally copied from, or
- check the page history for such edits, and merge the changes before pasting back.
Mistakes
Sometimes mistakes will be made in the merging process, because, well, Chris is human, and this may cause some of Andy's changes to be accidentally reversed. Logical edit conflicts aren't always immediately visible. Sometimes Chris may have good reasons for thinking that Andy's improvements aren't useful. In these cases, Andy and Chris are expected to resolve their differences amicably.
If Andy made a small change, which Chris accidentally reversed, then Andy must not revert to her version. It is absolutely not acceptable for Andy to reverse Chris's major improvements to the page out of a desire to protect her minor improvements, or to punish Chris for his carelessness. This is particularly important if the page has subsequently been edited by, say, Sarah and Jonathan.
The best approach for Andy in this circumstance is for Andy to edit Chris's version, reinstate her minor improvements, and leave Chris's major improvements intact. She may also add something to the edit summary to indicate that she had to do this - for example: "Reinstating link which Chris accidentally removed". Chris should then apologize to Andy for his mistake, and thank her for reinstating her improvement.
If Chris repeats his error, then the best approach is for Andy to have a friendly word on his talk page, point him to this page, and ask him if he could take a little more care in the future. This is particularly important for newcomers, who may not understand the correct way to resolve edit conflicts, though even experienced users may need the occasional friendly reminder.
Reverting
When saving a previous version (i.e. when reverting) or a new version based on that (a modified reversion) the edit conflict warning and prevention system is not triggered and a possible new edit made in the meantime is unintentionally reverted. To avoid this problem one can copy the text from the edit box of the old version into the edit box of the latest version. In some sense, this can cause hidden edit conflicts: you may overwrite someone else's changes without realising that you are doing so. It's always wise to check the diff after performing a revert, just as you would after posting via edit conflict. Preferably, one can simply try to avoid reversion wars.
Prevention
Because edit conflicts are irritating and time-consuming, you may choose to alter your editing habits to render them less frequent: aiming to make more edits to pages that have not been edited recently, such as those listed on ancient pages, for example.
Another means of avoiding edit conflicts is to make a single larger change, rather than frequent smaller changes: this makes it more likely that you will get an edit conflict, but less likely that you will cause others to get an edit conflict. Using the "Show preview" button helps here.
To reduce the chance of edit conflicts, Wikipedia has an "In Use" notice in its Template namespace that people may use when editing a page over a long period of time. Simply put "inuse" on an article before proceeding with a major edit, and remove the template when the editing is complete.
New since v.1.3 is CVS-style edit conflict merging, based on the diff3 utility. This feature will only trigger an edit conflict if users attempt to edit the same few lines.