One way around the limitation for single user edits (other than multiuser edits) is the use of a 3-way merge algorithm.

We now have a branch that contains 3 way merging (https://github.com/dokuwiki/dokuwiki/tree/3waymerge). To try it, checkout the branch and open the same page in two browser tabs editing in both on the same time.

There are some open questions that should be answered before merging this branch into master:

• Decide if page locking be disabled completely or should it be an option?
  • I think an option would be good, and I think plugins should also be able to force locking in order to prevent problems with editors that don't support merging (WYSIWYG, table editor, …) — Michael Hamann 2011/04/30 13:33
• Should we prohibit saving texts that contain merge conflict markers?
  • can we detect them without invoking the full parser?
    • we probably need to choose conflict markers that don't occur in the original text. I can't imagine this works using the parser with a fixed conflict marker, as it should a) be possible that these markers are used in the page content (e.g. in code or nowiki blocks) but b) conflicts inside code or nowiki blocks need to be marked, too. — Michael Hamann 2011/04/30 13:33
• Can the edit interface be enhanced to make working with conflicts easier?
  • eg. have a toolbar button to jump to the next conflict in the editor
  • automatically jump to the next conflict in editor when thrown back to it on conflicts
    • Yes, this is most probably possible and I think this (combined with a counter how many conflicts exist and maybe even jump markers like e.g. in Eclipse) would really be a nice feature (but it would need conflict markers that don't occur in the page already or we need to store + track the position where the conflict markers are). — Michael Hamann 2011/04/30 13:33
• We should have conflict markers visualized when rendering (for preview)
  • maybe show the whole conflicted part as a diff table?
    • I usually like to have a diff with all changes I did (including the conflict resolving), but this should be possible using diffpreview already. — Michael Hamann 2011/04/30 13:33
  • or just highlight the markers?
    • This is probably rather difficult, as the markers might be interpreted as syntax unless they are a syntax plugin, but then they might not work inside nowiki blocks etc. — Michael Hamann 2011/04/30 13:33
  • we might need better/different conflict markers
    • Probably unique diff markers that don't occur in the page already make sense. — Michael Hamann 2011/04/30 13:33
• Do we need some notification when somebody else is already editing? (e.g. when the automatic save is executed) and when the page is (re)loaded.
  • Yes, I think this really makes sense, as when somebody else is already editing users should be able to see that so they don't e.g. start restructuring major parts of the page. — Michael Hamann 2011/04/30 13:33
• When merge conflicts happen, the whole page is loaded into the editor currently, even when you were editing a section before - can we improve this somehow?
  • We could insert random section markers that occur in the page already before the merge and search for them after the merge, split the text again and see if there are any conflicts outside of the edited section. If there are any conflicts outside the current section the merge should probably be redone in order to prevent the section markers from being part of a conflict. — Michael Hamann 2011/04/30 13:33
• We currently have linelevel merges only. Is this good enough? Can it be improved? How?
  • We could try word-level merges, but that will probably merge too many things automatically. An interesting idea that has been suggested in one of the GSoC applications for this idea is imho splitting the text at “,”, “.”, “!” and “?” - but this only works for languages that use these characters. Maybe we could collect a list of such “split characters” for all languages? — Michael Hamann 2011/04/30 13:33

Related issue FS#679.