Edit Conflict Resolution
Edit Conflict ResolutionIf 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.
This is a little more complex than technique 1, but harder to accidentally lose your work.
Discussion about how to handle simultaneous edits
Consider...
Moved from WikiWikiBugs:
CliffordAdams 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. -- WardCunningham
06/Nov 23:11:57 StudentInformationProcessingBoard -- cosrel2.hp.com => ocsp-3.mit.edu 06/Nov 23:57:03 EditText -- cosrel1.hp.com => cosrel2.hp.com 08/Nov 01:37:30 SelfDocumentingCode -- cr824441-a.rchrd1.on.wave.home.com => zaleriza.owl.co.uk 08/Nov 13:18:16 SelfDocumentingCode -- ingenius.on.ca => 198.202.137.64 14/Nov 14:12:22 NatureOfOrderDiscussion -- 165.87.14.197 => cr824441-a.rchrd1.on.wave.home.com 16/Nov 06:41:54 WhoIsUsingJunit -- red.parallax.co.uk => 206.98.234.163 16/Nov 08:42:48 WayneConrad -- emprx7.aexp.com => emprx5.aexp.com 17/Nov 08:18:51 HungarianNotation -- emprx6.aexp.com => temagami.carleton.ca 18/Nov 07:17:29 WayneConrad -- emprx7.aexp.com => emprx6.aexp.com 20/Nov 23:21:10 AcompanyIsProsecutedForBeingAmonopoly -- port-5-221.magma.ca => pm3071.esva.net 21/Nov 10:51:12 DoesXpWorkForJava -- c1029014-a.bvrtn1.or.home.com => objectiv.demon.co.uk 22/Nov 05:14:11 WikiSuccessCanInhibitNewWriters -- objectiv.demon.co.uk => hil-qbu-ppu-vty63.as.wcom.net 22/Nov 21:19:54 XpTrowePrice -- dt101nd7.san.rr.com => abd77b7f.ipt.aol.com 23/Nov 06:36:33 VlissidesOnBeck -- ss06.ny.us.ibm.com => pix2-254.ameren.com 23/Nov 13:01:46 RecentVisitors -- ss10.ny.us.ibm.com => cygnusx1.meto.gov.uk 25/Nov 09:39:20 WikiPages -- sungold2.uk.ibm.com => ppp030.rz.uni-augsburg.de 26/Nov 07:37:26 SmalltalkIsaFailure -- pm3-01a2-port16.dundee.net => 193.123.236.130 27/Nov 13:32:31 WikiPortal -- d185fda63.rochester.rr.com => dt101nd7.san.rr.com 28/Nov 21:30:57 WhoIsUsingJunit -- myeah0.connect.com.au => ext-proxy.capitalone.com 28/Nov 21:57:33 WikiPortalStories -- cr824441-a.rchrd1.on.wave.home.com => dt101nd7.san.rr.com 28/Nov 21:57:47 WikiPortalStories -- dt101nd7.san.rr.com => cr824441-a.rchrd1.on.wave.home.comPage 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 DaveSmith, uses an independent index and has no impact on page reads and writes other than competing for system resources. -- WardCunningham
On may 1st I confirmed an odd property I'd noticed before. I can lock myself out of editing. Scenario: I start to edit MyFavoritePage? 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:
Options:
---
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. - GeorgeDinwiddie
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? -- WardCunningham
p.s. This may not seem like the SimplestThing, 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. -- DanielEarwicker
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:
<The other guys line >Your lineright 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 PessimisticLocking, 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 OptimisticLocking 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 EditText, 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 DoTheSimplestThingThatCouldPossiblyWork, 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 ThreadMode 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." -- JeffGrigg
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 EditCopy right now?
EditCopy 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 CyclicCvs:
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 --DanielEarwicker)
How do you handle cut and paste? Things get very complex and nasty very quickly. -- JeffGrigg
ThoughtsWeaver 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 LarryWall'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. -- ScottJohnston
See also: WillyWonkaConflictResolution
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 LarryWall's patch utility. If successful, changes made by the last person to save are merged with the changes made while they were editing. -- ScottJohnston
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. -- DonaldNoyes
What happens when two people independently edit the same page at the same time?
Good question.
In 2000 this wiki's creator, WardCunningham, implemented an EditConflictResolution 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 OptimisticLocking, but it is needed in a distributed edit environment such as WardsWiki.
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 InternetExplorer, 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. InternetExplorer, 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 WikiPedia 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. -- AnonymousDonor
I totally agree, that would probably be the easiest way while also being somewhat convenient. -- Dilligent
EditText of this page
(last edited April 10, 2012)
or FindPage with title or text search