Edit Conflict Resolution

If two or more people try to edit a page simultaneously, the first one to save wins and the rest are notified that they can't save. Should you be so notified, try opening a new edit window in a new browser and copying your changes to it. See the techniques below for details on how to do this.

Merging your changes (technique 1)

This is simpler than technique 2, but risks losing your work: For a little while, your changes exist only in the clipboard.

"back" your browser to get back to your edit

copy your edit (under Windows, mark it with the mouse or keyboard and then use control-c to copy it)

"back" your browser again to get back to the page

"refresh" the page

See what changed

Click on the "Edit" button

Paste your changes into the page (under Windows, control-v)

Merging your changes (technique 2)

This is a little more complex than technique 1, but harder to accidentally lose your work.

"Back" your browser to get back to your edit

"New window" your browser. The new window is a backup copy of your changes.

Select your old window and perform the remaining steps in it.

back your browser to get back to the page

Refresh to pick up the changes made by the other editor.

Click on the "Edit" button.

Copy your changes from the backup window you made in step 2, carefully merging them in with the first author's changes.

Click on the "Save" button.

Get rid of the backup window.

Discussion about how to handle simultaneous edits

Wiki used not to refuse the second save. Most of this discussion was written when the last save won.

Until something is implemented, however, it's probably sociable to not spend an excessive time on the edit page, especially on pages that are getting "lots of discussion on them" at the time.

Consider...

Stepped On My Edit

Cautions While Editing Text

Moved from Wiki Wiki Bugs:

Clifford Adams has convinced me that I have to at least detect editing collisions. I warmed up by running a month of old logs through the logic he suggests. And the answer is, yes, pages are getting clobbered, about once a day. The results from my simulation follow. -- Ward Cunningham

Page reads can block writes and vice versa due to db level locking. Fortunately, both are fast operations so the condition does not persist. I will have to change db again to improve this. At one time, wiki did hold a read lock on the db while searching and people get locked out while browsing as a result. My new implementation, suggested by Dave Smith, uses an independent index and has no impact on page reads and writes other than competing for system resources. -- Ward Cunningham

On may 1st I confirmed an odd property I'd noticed before. I can lock myself out of editing. Scenario: I start to edit My Favorite Page and save it. There is a spelling error. I click "Back" and edit the mistook out. I save the new page and get the "I can't do that Dave" message. However the mistooken page has been saved so I come back to it later.

Ok lets go through this in simple detail. There are two people named player1 and player2. Both player1 and player2 have the edit page open simultaneously.

2 different cases we need to handle:

One of them hits "save". Then later the other one hits "save".

One of them hits "save". Then later the other one decides not to make any changes after all, and closes the edit window.

What should the wiki do?

Options:

Last one wins. This is generally regarded as a bad option, because whoever saves first has no warning that his work has been completely overwritten. "Whoever saves last is the work that is put onto the page. So if player1 saves his work last, he/she is really erasing what player2 has changed and just putting in his/her work in place of player2's work. It's pretty simple because what player1 and player2 have open will not have the changes or corrections that either one has made, in it's stead they both have separate files that have just what the page previously had (before being edited by either player1 or player2.)" -- Roland Sin.

First one wins. This is better, because it saves the first person's work, and it's possible for the wiki to give some sort of warning message to the 2nd person.

some sort of complicated auto-merging thing.

File locking Somehow allows only one person at a time to edit the page. In other words, "lock" the page when the first person tries to edit it, "unlock" the page when that person is done. Could be done using semaphores in Unix, or by dbm file read/write locking (I don't know how that would work with Perl). When someone tries to edit a locked file, give that person a warning that it is being edited by someone else. (When someone is editing a page, then decides not to make any changes and simply turns off his computer - is there any way for the wiki to realize that person is done and unlock the page ?)

Is there any other way for a wiki to act?

---

Even if the transaction has timed out, there's no need to refuse the edit if no one else has tried to edit the page. It's probably only worthwhile checking the timeout when someone tries to edit the page and it's currently locked. That's the time to unlock it and the lock it for the second user, assuming a time greater than the timeout has already passed. - George Dinwiddie

I'm certain Ward knows N ways to fix this: it's a question of whether it's worthwhile. As wiki grows, it's starting to look to me like maybe it is. -- rj

I am looking for change-merge heuristics for another application. I want to be able to reconcile changes in the presence of page reorganization. My best strategy so far is to capture editing gestures in the gui, map those to a stream of deltas in a related semantic space (like whole phrases), then concatenate streams in all possible orders and look for differences. If none, I've successfully merged. Any better ideas? -- Ward Cunningham

p.s. This may not seem like the Simplest Thing, but a workable solution simplifies a dozen other parts of the system.

Problem with above is that it may often produce something which is slightly wrong in a lot of little separate locations, and then the user needs a way to navigate through all those fixing them up, i.e. something that needs a good refactoring. I'm guessing a common reason for making a lot of little edits is when refactoring a page or three (as you put it, page reorganization.) If two users try to refactor something simultaneously, my gut feel is it's time to give up on the merging! Here's a benchmark for deciding whether an idea is worth following: The closer you get towards wanting the editor to be capable of "automatic" merging in such a wide variety of circumstances... the closer we are to talking about something that actually knows how to refactor well! And look at how difficult it is to explain to people how to do that, let alone "explaining" it into some software! Much of the content here is about grappling with that little problem. -- Daniel Earwicker

The merge strategies that I've seen generally do the obvious stuff for you and then leave the rest up to the latest author. Wiki could do this by putting marked up text into the page and dumping the second author back into edit mode. You'd end up with something like:

right in the middle of the page. The second author would then have an opportunity to make the page look right and check in.

You don't want to do Pessimistic Locking, because (1) people may go into edit mode and then navigate to another page or kill the browser, and (2) you don't normally want to hold locks during end user "think time," while waiting for user input.

A very commonly used Optimistic Locking technique is to use a timestamp (or a checksum, or a version number). Notice the "(last edited April 15, 1999)" text at the end of the page: If this contained the last update time, to the millisecond, as measured by the server, then one could easily detect conflicting changes. It works like this: When you select Edit Text, the server puts the last edit date/time (or a checksum of the entire page, or the version number) on the edit page in read-only field (perhaps a hidden field). When you press the Save button, the server compares that read-only field to the date/time (or the checksum or version number) of the record you're about to update. If they're different, you have a conflict - someone else was the first person to submit a change - so the server should refuse the save with a rude message about how slow a thinker the (second) editor must be. If they're the same, there's no conflict - you're the first person to submit a change - so the server should update the page with your new text (also updating its timestamp or incrementing its version number).

This technique is very common in relational databases.

Now for the hard part: Merging changes. To Do The Simplest Thing That Could Possibly Work, tell the 2nd saver that their changes conflict, and let them work out the conflicts by hand. If conflicts are rare and simple, this can work well.

If you want to provide automated assistance, I've seen version control systems be quite effective with automated merging based on doing "diff"s of the new versions, relative to a common ancestor, and merging the changes. If the two editors made changes to some of the same lines, just put both versions of those lines in the output and ask the humans to resolve it.

(GNU "diff" does automated merging, and has a mode to put #ifdef/#else/#endif C/C++ macros around areas of conflicting changes.) This wouldn't take more than an hour to code up in Perl, I'm sure.

A special case to consider: In Thread Mode discussion, it's common for both authors to add text at the end. Recognize this as a special case, and just add the 2nd saver's text after the 1st saver's text, and treat this as a "automatically resolved conflict."

-- Jeff Grigg

P.S. If I save, and then use the browser to back up a page, the checksum or timestamp won't be right. Probably need some way to deal with that. (I think there's no need to do anything special in this case. If someone is looking at a old version of the page, with an old timestamp, then if that person chooses *not* to make an edit, everything's OK. If that person *does* choose to make changes to this old, obsolete version of the page, the above algorithm gives him a warning - hopefully he soon learns to hit the "refresh" button just before editing a page.)

How does that substantially differ from what happens with Edit Copy right now?

Edit Copy doesn't stop page smashes. The above approach does.

Somehow, I suspect that Ward is beyond just trying to stop page smashes. Most page collisions will be non-conflicting, so being optimistic as well as friendly, the algorithm Ward described will try to give the players the benefit of the doubt and merge their changes. Having gone that far, he can easily detect conflict and generate a (polite) message.

On the contrary. Whenever a page smash occurs, the edit of the first person is lost. Unless I'm more stupid than usual, that's the topic of the page.

Yes, I'd humbly suggest that locking isn't an appropriate strategy here. How long should locks stay valid? What's to prevent abuse of the locking? Merging is plainly called for. Probably the easiest way would be to rely on the multiple checkouts/checkin facilities of Cyclic Cvs:

Player 1 edits a page.

Player 2 edits the same page.

player 1 saves their edits - fine, page saved (checked in).

player 2 tries to save their edits. Instead of getting their changes accepted, their deltas are merged with the deltas since the version of the page they tried to edit - use the perl interface to CVS - and they're given a new page showing the diffs/conflicts color coded. Except for the color coding, this is what cvs update does.

player 2 can then choose to edit the merged text - to make certain there's a valid copy, send it along in a hidden field in the merge page - or they might forget about their edits.

if player 2 saves, then you do a cvs checkin.

If player 2 doesn't check in until after someone else - say player 3 - checks in more edits, then just repeat the process. That's to say you always want to merge

player 2's original page

player 2's total edits

the delta between player 2's original page and the most recent saved version of the page.

CVS will do all of this for you except the merge coloring. It's tempting, as per Atis Wiki, to keep and give access to the whole page history too, but I'd suggest that's not actually in the interest of the Wiki Nature - keeping accessible page histories isn't Why Wiki Works. -- Peter Merel

Way too complex. Unnecessary complexity. Do you really want to write a text editor in Java?

(If you did that, you could make it WYSIWYG and people would have an easier time doing bulleted lists, and so on... but I think that would destroy a lot of the character and flavour of the Wiki experience --Daniel Earwicker)

How do you handle cut and paste? Things get very complex and nasty very quickly. -- Jeff Grigg

Thoughts Weaver uses locking. Locking times out after a parameterized time limit (usually set to about an hour). If you try to edit a locked page, you are given a warning. The warning tells you what it can about the site that has the page locked, and about how long it's been locked. If you feel confident that you should go ahead and edit the page anyhow, you are given that option. So, it's a lock to which everyone has a key - it's a lot better than an open door, and better than punitive locking.

How about using Larry Wall's patch to merge parallel changes to the same file? Whenever this occurs, a diff could be generated between the original and 2nd edited version, and patch used to apply this diff to the 1st edited version. I bet it would work 95% of the time, and the 5% failures could be reported back to the 2nd editor with apologies. Better than the 1st editor having their work lost without a clue. -- Scott Johnston

See also: Willy Wonka Conflict Resolution

Does this work? -- Lam

Sure it "works."

And what I mean by that is that the changes made by the last person to save overwrite changes made while they were editing. This is an undesirable outcome, but who's to say it's "wrong?"

The above comment is wrong, at least if it was referring to the use of Larry Wall's patch utility. If successful, changes made by the last person to save are merged with the changes made while they were editing. -- Scott Johnston

How big of a problem is this? From all the discussion here, it sounds like edit-collisions are happening to people all the time, but I haven't experienced them that much, not nearly enough for me to see an automated solution as desirable.

May I suggest a solution that avoids the problem of save collisions entirely: implement the wiki so that you can see what the other editor(s) are typing, in real time. Something like a cross between a WYSIWYG text editor and IRC. Imagine seeing a whole lot of other users' cursors running around a busy page, cutting and editing their sections while you were editing. That would be cool and useful. -- Tom

This is just what happens when you start EMACS in server mode and connect multiple clients to it. But this has nothing to do with a browser.

-- Beat

Cool and useful, perhaps. Easy and cross-browser-compatible, no.

Just 'cos it's hard doesn't mean it shouldn't be tried. Cross browser compatibility... hmmm... would it be worse than a java chat applet, which run on the major browsers? - Tom PS, I note the irony that I've been locked out by you during the last two times I tried to update.

Another method, quite successful, is to use the methods at the top of the page plus -> (save the page textmode)(save the change textmode) then come back again in an hour, to see if your edit made it, if not then do it again. (If you have to do this more than once, just lay off the page, it's to hottohandle. Let it settle for a day, a week or a month) You have as much time as God will grant you to make whatever changes you need to make. If what you want to post will endure the test of time, so should you. -- Donald Noyes

What happens when two people independently edit the same page at the same time?

Good question.

In 2000 this wiki's creator, Ward Cunningham, implemented an Edit Conflict Resolution strategy - namely, first save wins.

Suppose two people start editing a page and one of them saves. If the second person were permitted to save, their changes would wipe out those of the first person. Instead, when the second person tries to save, they get an edit conflict message. This gives them the chance to back up to the edit window, cut their new text from the browser window, then reload the edit page and reapply their changes.

The system works by checking the timestamp of the original version of the page against the timestamp of the page about to be overwritten. If the timestamps are the same then the page hasn't been changed and the save is allowed. If the timestamps differ then the page has changed and the version about to be overwritten contains new work. Hence the newer version must be loaded and the changes applied to that.

Note that this check is not made if the two saves are by the same person. If you open two edit windows on a single page, make different changes to each, then save them one after the other, the second save wins. This is because changes made by one person are "rolled-up" and considered as a single change.

This isn't really anything special, see Optimistic Locking, but it is needed in a distributed edit environment such as Wards Wiki.

If two authors edited different parts of a page (in other words, the set of "diffs" were disjoint); any possibility of applying them both?

It would be nice, but suppose the changes made by one person at the bottom of the page referred to text at the top that has independently been reworked, or even deleted. In this case there is no guarantee that the page would remain coherent, and since people are notorious for not double-checking it's probably better to do the simplest thing and let people resolve the occasional collision by hand.

I can't tell you how many times I've written paragraphs of text into a page, only to have it all silently discarded when someone else, editing the same page at the same time, saved after me. This encouraged making small changes and saving often. ... which was, in a sense, a good thing. But it was also very frustrating, at times.

If you use Netscape instead of Internet Explorer, the text entry box on the "edit" page will retain your text when you navigate back to it in the browser - even after this conflict. Internet Explorer, unfortunately, refreshes the text entry box automagically (killing your unsubmitted paragraphs).

With IE, I simply go back and my text is still there.

Every time at dinner, mom used to call the kids to the table and make us eat one at a time. Crikey, at least cook the kids first!!

Why not take the CVS approach (such as Tortoise supports)? When the second to arrive edit version arrives, either it is easy to incorporate with the first or the second editor (who has not been told that his or her edit was accepted) *OR* the specifics of the text conflict are articulated. The second editor will have the opportunity to make the minimum changes to the co-linear text tract. -- DocM

Just as the Wiki Pedia does: if some other user (John, say) edits the page while I am editing it, my changes are not automatically saved - instead, when I click Save, I get to a page where both John's and my version are displayed, and the merging work is left to me. -- Anonymous Donor

I totally agree, that would probably be the easiest way while also being somewhat convenient. -- Dilligent

Category Wiki Category Wiki Editing

See original on c2.com