View Full Version : Merge support and conflict handling
mreuvers
08-28-2007, 01:55 PM
Hi,
Since Deki Wiki is a fork of the MediaWiki project, I was wondering if you guys support merging of articles. Suppose two people work on the same page at the same time, the one that posts his changes the latest should be confronted with a conflict page that merges the two pages and presents the user with a diff between the page he edited and the page the other guy edited.
I know this is a feature in MediaWiki, however we couldn't find it in Deki Wiki. Deki Wiki seems to overwrite the article, regardless if it has been changed in the meantime. Can we somehow use the MediaWiki handling instead?
Cheers,
Martijn
Hey Martijn,
Although Deki Wiki was originally based on MediaWiki's codebase, we've diverged greatly over the past 7 months; all the business logic is handled in C# now. We'll examine our conflict resolution strategy a bit more for Itasca.
mreuvers
08-28-2007, 08:40 PM
smashing... if you need input for ideas, just let me know. We got a company full of geeks that have some very good ideas about how a merging tool should behave ;)
Cheers
SteveB
08-29-2007, 08:23 AM
You do? Well then :)
All input is stored in XML, more precisely XHTML. This makes merging between edits quite a bit harder, b/c you cannot simply go off line diffs. Instead, you have to do a tree graph comparison with distances between sub-trees. This problem quickly grows in complexity and becomes NP complete, which means it's very expensive to compute.
I've been scratching my head over this for a while and would welcome any suggestions on how a three-way merge can be done. A good starting point might be the XDocDiff class which already computes XML diffs between pages.
pvanzelst
08-30-2007, 03:47 PM
Would it be an idea (or even feasible) to parse the XHTML into a DOM tree, and do diffs based on that? That way you can see if the overall structure of the document changed. Then traditional line-based diffs (or other diffing methods, whatever is currently being employed by Deki Wiki) can be used for the actual text content.
With a DOM approach, it would be possible to provide pretty detailed change information, such as changes in links, images, etc.
If I knew anything about the inner workings of Deki Wiki, I'd love to contribute where I can. Where possible, I could even try my hand at the kind of diffing/merging approach I suggested above.
pvanzelst
09-04-2007, 04:25 PM
Can I conclude from the deafening silence that this was a silly idea? ;)
AaronF
09-04-2007, 04:42 PM
It's not silly it is just a very difficult algorithm. This is the topic for a doctoral dissertation. The problem is NP-Complete. :(
jgable
09-04-2007, 05:32 PM
May be a crazy idea but could opening the editor set a lock flag in the db that is checked before someone else can edit the page?
I am thinking the lock is just a timestamp that is sent every few minutes by the editor for the open page. If the editor is exited then the timestamp is reset. If the timestamp is > 10 minutes old it is considered expired when someone else tries to open the editor to acount for people just closing the browser without saving or exiting. Possibly include the editor in the message so you can talk to the person if required.
Maybe even put a notice at the top of a page that is being edited (This page currently being edited by jgable) if you go to the page.
From what I have seen most Wiki info isn't updated on an hourly basis and if you have something that multiple people are editing a lot I would say it should be devided among pages to minimize the interaction. That said you do need some way to prevent colisions but I would say it should be simple (Don't put 2 developers on it for 6 months and ignore other features).
SteveB
09-04-2007, 06:37 PM
We might add a warning message in the editor if the same page is already being edited by someone else. Petrus4 suggested a similar idea. But in the end, we have to handle merging of edits better. Sometimes you want to work simultaneously on the same contents and that won't be possible until merging works as it should.
DmitryA
09-05-2007, 08:10 AM
May be a crazy idea but could opening the editor set a lock flag in the db that is checked before someone else can edit the page?
Yes, this is a bad idea, but easy to develop.
jgable
09-05-2007, 02:52 PM
I guess I don't do the same kinds of things others are doing. Is it common to have editing collisions in the Wiki. Does it happen 10 times a day, once a month?
I'm just concerned that limited resources are spent on something that happens only rarely. I'd rather have the effort spent on making the editor rock solid.
Powered by vBulletin™ Version 4.1.3 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.