Improve handling of conflicts due to concurrent Wiki edits

[daniel]

It should be possible to prevent conflicts and loss of data during concurrent editing by multiple users.

MoinMoin handles this situation by locking a page for a maximum amount of time T while editing (other wikis do probably similar things).

See: http://moinmoin.wikiwikiweb.de/HelpOnEditLocks

[daniel]

As previously discussed in the IrcChannel;

A simple scheme where we simply include the latest page-version in the html form, then compare to the database upon commit (failing if someone has already edited it) is probably good enough for 0.7.

[cmlenz]

Ticket #723 has been marked as duplicate of this ticket.

[anonymous]

Ticket 723 has a more advanced proposed solution.

[eblot]

As a reference, the ML thread about implementing this feature.

[anonymous]

Ticket #2653 is a even more complex proposal to this issue and marked as duplicate.

[srussell@…]

(For the record, I reported #2653 which is more of a dupe of #723 than of this particular ticket. Both #2653 and #723 request some sort of diff/merge functionality for page submit conflicts.)

While locking may be the simplest solution for concurrent page edits, I don't feel that it solves the real issue - it only defers the problem. Furthermore, it complicates things for the second user who wants to edit the page, since they have to wait for however long it takes the first editor to finish (submit), assuming they are able to refresh the timeout period.

In a message in the thread referenced above:

I think the wiki idea is more like ''anyone can write at any time''.

I agree with this and locking is contrary to this notion. The same message goes on to mention a merging model.

Admittedly, I'm not sure what complexities are with merge/diff-ing conflicting page edits (either simply with conflict markers or by leveraging/extending the wiki diffs), but I personally prefer more usable approaches when practicable over simpler approaches. (The two do have to be balanced against each other of course, and perhaps that's been done already).

Some other thoughts:

• Say I'm the first editor. I start editing my wiki page. I get distracted (e.g. telephone call, or even just forgetting to refresh my lock) while I'm editing a page. My 10 minute timeout expires, another person (or persons) edit the page in the meantime. My phone call ends and I return to work on my page only to find out that it's been edited by someone else. Now I have to spend the effort (which is currently not straightforward) to merge my changes into the current "tip of the page". In short, the lock didn't do anything for me.
• The person trying to be the second editor of the page won't know how long it will take for the first editor to complete his/her work. Something like adding a simple comment in a specification, for instance, could become an exercise in frustration as the person waits for the page lock to be released (or give up trying). If somebody spends a couple of hours writing a section of a larger document (which could admittedly be broken into subpages to help alleviate the problem), then a second person will be prevented from making changes to other sections. If this was simply web page pulled from a source control system (as is the case at my day job), people could edit and merge changes freely. Which is much more useable? I feel, in this scenario the lock hindered my workflow.
• The locking model for wiki pages may force the user into a specific way of working, i.e. towards submitting lots of intermediate changes. As a contrary view, a programmer would typically not commit his/her code changes before it was "ready" to be checked in. Editing a wiki page shouldn't be any different. Which is better for the user?

That's my US$2 worth (I apologize for the length).

[bfults@…]

Has this reached any sort of resolution? We're seeing more and more conflicts with a larger development team and would love a simple merging interface for wiki conflicts. It doesn't have to do anything fancy -- just a simple side-by-side diff with radio buttons to select the appropriate side for each difference would work fine.

Is there a separate ticket for the wiki merging feature? If not, I propose a rename of this ticket to reflect the "merging" angle if this is indeed the approach that Edgewall wishes to take.

[alexandre.bourget@…]

Any development in that ticket ? Any merging functionality developed somehow ?

[sid]

This is currently slated for milestone:1.0. The development team is hard at work on 0.11, so probably no work done on this yet. However, you are welcome to submit a patch to help speed things up. :)

[cboos]

Also related to #1024: when different sections are edited, it should be possible to merge the changes automatically.

But that's probably just a special case that could be handled by a merge algorithm. That shouldn't be that hard to do, given a pair of diff datastructures; the conflicts marker could either be recognized by the Wiki parser and highlighted specially, or even more drastic, the presence of conflict markers in the text could prevent the page to be saved (but what happens when copy/pasting code snippets containing conflict markers?).

[cboos]

I'm updating the summary for this ticket, to better reflect the intent of this ticket which initially exposed a real problem but proposed the wrong solution. Locking is not the way to go, for the reasons exposed in comment:7.

[techtonik@…]

What about comment:1 - is there at least pre-commit check with database to detect if a newer version of a page exists when committing edit?

If there is then I would close this bugreport and fill another one about diffs and merges. From the ticket description it is more important for me that the data loss occurs.

[cboos]

Looking at this again, this is the status so far:

• no risk to overwrite changes made by others, as collisions are detected.
• no risk to loose one's own edits upon collision, as the content of the textarea is preserved and displayed

However, from that point, there's only the option to Cancel the edit, which forces the user to save his edits externally, and do a manual merge with the new version. This is clearly sub-optimal as the merge could be assisted. While a full-blown 3-way merge interface is probably out of the scope even for 1.0, offering the option to manually Merge changes would probably be useful.

[cboos]

Adds a Merge changes action in the collision view. Probably needs more testing, but gives the idea.

[cboos]

Reworked patch applied in r5856.