Edgewall Software

Opened 20 years ago

Closed 16 years ago

#152 closed defect (fixed)

Improve handling of conflicts due to concurrent Wiki edits

Reported by: daniel Owned by: Christian Boos
Priority: high Milestone: 0.11
Component: wiki system Version: 0.5.2
Severity: major Keywords: concurrent edit
Cc: bfults@…, mbertheau@… Branch:
Release Notes:
API Changes:
Internal Changes:

Description (last modified by Christian Boos)

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

Attachments (1)

wiki_merge_changes-r5851.diff (3.6 KB ) - added by Christian Boos 16 years ago.
Adds a Merge changes action in the collision view. Probably needs more testing, but gives the idea.

Download all attachments as: .zip

Change History (20)

comment:1 by daniel, 20 years ago

Milestone: 0.7

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.

comment:2 by Jonas Borgström, 20 years ago

Milestone: 0.71.0
Priority: normallow

comment:3 by Christopher Lenz, 19 years ago

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

comment:4 by anonymous, 18 years ago

Ticket 723 has a more advanced proposed solution.

comment:5 by Emmanuel Blot, 18 years ago

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

comment:6 by anonymous, 18 years ago

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

comment:7 by srussell@…, 18 years ago

(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).

comment:8 by bfults@…, 17 years ago

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.

comment:9 by bfults@…, 17 years ago

Cc: bfults@… added

comment:10 by alexandre.bourget@…, 17 years ago

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

comment:11 by sid, 17 years ago

Keywords: helpwanted added

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. :)

comment:12 by Christian Boos, 17 years ago

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?).

comment:13 by Markus Bertheau <mbertheau@…>, 17 years ago

Cc: mbertheau@… added

comment:14 by Christian Boos, 17 years ago

Description: modified (diff)
Keywords: concurrent edit added; helpwanted removed
Milestone: 1.00.12
Owner: changed from Jonas Borgström to Christian Boos
Priority: lownormal
Summary: Locking pages while editing to prevent conflictsImprove handling of conflicts due to concurrent Wiki edits

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.

comment:15 by Christian Boos, 17 years ago

Milestone: 0.120.11

comment:16 by Christian Boos, 16 years ago

Priority: normalhigh
Severity: normalmajor

comment:17 by techtonik@…, 16 years ago

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.

comment:18 by Christian Boos, 16 years ago

Status: newassigned

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.

by Christian Boos, 16 years ago

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

comment:19 by Christian Boos, 16 years ago

Resolution: fixed
Status: assignedclosed

Reworked patch applied in r5856.

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain Christian Boos.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Christian Boos to the specified user.

Add Comment

E-mail address and name can be saved in the Preferences .
Note: See TracTickets for help on using tickets.