Is there any way that we can improve conflict resolution?

Our project collaborates on a project status report each week. When two or more edit concurrently, the resulting topic contains many strikeouts that takes quite a while to resolve. The project requested all users to not edit when someone else is editing and even asked the administrators to have the files lock (not an adequate solution).

We believe that when conflicts exist, the merge comes back in two forms - either a series of conflict paragraphs or paragraphs with strikeouts. It appears that the conflict paragraphs are easier to resolve than strikeout paragraphs.

We did some testing and found the following:

Edit Sequence By Two Individuals	At Least One Edits in Raw Edits@		Both Edit in WYSIWYG
	Different Paragraphs	Same Paragraph	Different Paragraphs	Same Paragraph
Person 1 Edits Person 2 Edits Person 2 Saves Person 1 Saves	Merges Perfectly	Paragraph results in Conflict Paragraphs Original Person 1 version Person 2 version	1st Persons paragraph results in Conflict Paragraphs Original Person 1 version Person 2 version	Paragraph results in Conflict Paragraphs Original Person 1 version Person 2 version
Person 1 Edits Person 2 Edits Person 1 Saves Person 2 Saves	Strikeouts in Both Paragraphs	Strikeouts in Paragraph	Strikeouts in Both Paragraphs	Strikeouts in Paragraph

@ Since we tested with two users, It may be "No more than One User using WYSIWYG*

If we analyzed this correctly, it appears that we may improve our chances of success by editing in raw mode but, even more important, having a user's editing session contained within another user's editing session (and not interspersed). This would suggest the philosophy that if you are going to edit when someone is already editing, then edit quickly and finish before the other user does.

Interested in any comments.

nice analysis - you're right, we should be able to find a way to improve the merging. One possible thing you could do now, is to partition the report into separate topics, and then use INCLUDE / viewtemplates to merge the information, but that might not be appropriate (and is really a workaround for what is clearly a suboptimal result)

-- SvenDowideit - 29 Apr 2010

We've had this too, so the strategy is to avoid large documents.

It would be reasonably easy to do a TinyMCEPlugin where you could select a region of text, and click new toolbar buttons to either keep the strikeouts or keep the insertions; users could cherry-pick then.

In this scenario, it would be useful for the <ins>=/=<del> tags to contain eg. a title= attribute that would help identify a chunk of text as being associated with a a user at a particular time.

-- PaulHarvey - 30 Apr 2010

Yeah, I've often thought how nice it would be to have a proper conflict resolution UI.

Add a FeatureProposal (see FeatureRequest)

-- CrawfordCurrie - 08 Jul 2010

partition the report into separate topics, and then use INCLUDE

In case it's not grokked by current/future readers, Sven's suggestion actually becomes a lot more usable in combination with EditChapterPlugin. If the editors don't edit the entire topic but instead used the edit icon that EditChapterPlugin produces beside the header/section titles, you can edit included content from the including document without even being aware that's what you're doing if you fail to notice the URL.

So putting it another way, everyone starts their edits from the same topic but in fact are seemlessly redirected to editing separate topics which you've included into the main topic. Now if two editors edit the same paragraph you're still in a merge scenario. You point out that merges currently are more successful if editing raw. EditChapterPlugin opens a raw edit session, even if WYSIWYG is the enabled default for the site.

-- CraigBowers - 13 Jul 2010