Quand deux personnes A et B voient la révision X de la page en cours et que les deux commencent à éditer la page, alors A sauvegardera la révision X+1, et B expérimentera un conflit d'éditions.
Il existe plusieurs moyens d'arranger ça :
La dernière modification gagne. Dans ce cas les modifications de A seront perdues. Une solution pourrait être un avertissement pour montrer quand B effectue une sauvegarde : "La page a été modifiée il y a 42 secondes par A. Merci de vérifier si vous désirez écraser toute modification". Cette solution est probablement la plus simple à comprendre pour les utilisateurs.
Exemples : aucun.
Utilisez un chronodatage sur la page édition et au moment de sauvegarder une révision, assurez-vous que personne n'ait sauvegardé une nouvelle révision dans ce laps de temps.. Dans ce cas, B sera prévenu que la page originale a été modifiée, et que ses modifications ne pourront pas être sauvegardées. Ceci est accompagné habituellement d'une petite phrase de dialogue qui permet à B de comparer sa révision à la nouvelle révision et de la soumettre à un mixeur manuel. Ceci est surprenant et compliqué pour les utilisateurs, mais c'est facile à coder.
Le temps passé pour intégrer les modifications peut agir comme une sorte de DifférerAction dans les guerres du feu et assimilées. Quand il existe une tension parmi les contributeurs, peu de conflits d'éditions sont brusquement perçus comme des éditions intentionnelles ("Oh mon dieu, tu as effacé mes commentaires ! Toi le XXXXX !") Aussi, il est mieux si B patiente jusqu'à ce que A ait complètement fini de commenter, parce que B pourrait prendre en considération les éditions de A.
D'autres pressentent que le désir d'éviter les conflits d'éditions (qui sont douloureux) amènent les personnes à écrire rapidement et avec peu de pensées.
Exemples : UseMod, WikiPedia, WikkiTikkiTavi
Utilisez un chronodatage sur la page édition et au moment de sauvegarder une révision, fusionnez la nouvelle révision avec la page éditée. Les outils de commandes en ligne tels que le merge et le diffs fusionnent de manière algorithmique deux révisions en se fondant sur leur ancêtre commun (les systèmes de contrôles de versions comme CVS utilisent ceci).
Parfois, néanmoins, les conflits ne peuvent être résolus intelligemment, par exemple si A et B ajoutent tous les deux du texte qui se chevauche. les outils de fusion peuvent ajouter des marqueurs spécifiques de conflits pour produire le résultat, ce qui facilite la résolution de conflit pour l'éditeur. Il y a néanmoins plusieurs choix :
La dernière option, en particulier, permet au travail fusionné d'être fait quoiqu'il puisse se passer. Malheureusement, ce peut aussi mener à des cycles de conflit, parce que les personnes essayent sans discontinuité, d'essayer de réparer les conflits précédents, et bien sûr, rentrent à nouveau en conflit. Le seul recours restant étant une solution hors-ligne, une conclusion sur-optimale.
Voir FusionAutomatique pour plus de détails sur les marqueurs de conflit.
Une autre option est de verrouiller la page dès que A décide d'éditer la page. Ceci exige un certain laps-de-temps, parce que A pourrait très bien décider d'abandonner son édition. Une fois le blocage-temps terminé, nous sommes dans la même situation qu'avant. Si le laps de temps s'est écoulé, le wiki pourrait simplement empêcher de sauvegarder les modifications. Combiné avec un chronodatage, le wiki pourrait simplement empêcher de sauvegarder la modification si quelqu'un d'autre créait une nouvelle page dans le laps de temps. A ce stade, toutes les solutions mentionnées plus haut pourraient être utilisées, mais si le laps de temps est suffisamment long, il n'y a souvent pas besoin de résoudre ce problème. Un délai long pourrait être un problème pour les sites où beaucoup d'utilisateurs abandonneront les éditions.
Ce comportement peut être exploitable par des spammers utilisant des robots : poster du spam, puis verrouiller la page de façon répétée pour empêcher quiconque de revenir en arrière.
Exemples : MoinMoin