Item10788: Reduce edit collisions with EditChapterPlugin

We use Foswiki for a whole lot of different tasks, among is meeting minutes taking, where all participants provide there known contributions before the meeting starts in a shared wiki topic. As closer the meeting gets, the higher the activities on the topic become. Often several user add there contribution concurrent, encouraged by Foswikis alleged capability to merge all those contributions. But, unfortunately, Foswiki creates to often ugly collision topics, even if author where clearly working in different sections.

Users are specially disappointed, because the topics are well prepared with all the necessary headers and all contributor agreed on only edit there respective sections by editing with chapter edit ( Icon next to the headers).

We now added the following functionality to EditChapterPlugin:

• If editing a topic was invoked by chapter edit, save tests, whether the topic has changed in the meantime:
  • If the topic has not changed: proceed without addition action
  • If the topic has changed: check, whether the chapter, the author is currently editing has changed
    • If the chapter has changed: proceed without addition action. Lets Foswikis collision resolving try its best
    • If the chapter has not changed: Update in the current editing page the areas before and after the edited chapter and update the original revision info. Foswiki will save the topic, as if the edit sessions where sequential and not parallel

The following code was created:

Wenn mehrere User gleichzeitig an einem Wiki Topic arbeiten kommt es beim speichern zwangsläufig zu einem Konflikt. Foswiki versucht die parallel gemachten Änderungen einvernehmlich zusammenzuführen, doch mit sehr unterschiedlich Resultaten. Häufiger als eigentlich nötig, wird bei Konflikten das Topic mit zahlreichen ins und del Tags durchsetzt. Dies leider oft auch unnötig, wenn die User nämlich EditChapterPlugin einsetzten und nur in einem getrennten Bereich gearbeitet haben.

Dieses Modifikation soll die Zahl der erfolglosen Merger im Einsatz mit EditChapterPlugin stark reduzieren.

Die Verbesserung scheitert:

• Zwei Nutzer ändern gleichzeitig das selbe Kapitel
• Die Überschriften Struktur ändert sich, so dass ein soeben verändertes Kapitel zum Zeitpunkt der Speicherung nicht mehr an der selben Stelle zu stehen kommt wie zuvor

Sollte die Verbesserung scheitern, kommt weiterhin Foswikis Merge Funktion zu Zug.

edited File

templates/edit.chapter.tmpl

*** 2,4 ****
  %TMPL:INCLUDE{"editjavascript"}%<!-- editjavascript// -->
- %TMPL:DEF{"textarea"}%<!-- textarea -->
+ %TMPL:DEF{"textarea"}%<!-- textarea -->%TMPL:P{"neweditchapter"}%

new Files

templates/view.chapterrevision.tmpl (new)

To get the current topic revision information

%REVINFO{"$rev_$epoch"}%

templates/view.chapteredit.tmpl (new)

To get the topics content split in beforetext, paragraph (selected chapter) and aftertext.

<noautolink>
<textarea id="beforetext">%EXTRACTCHAPTER{before="%URLPARAM{"from" default="0"}%" encode="on" id="2"}%</textarea>
<textarea id="paragraph">%EXTRACTCHAPTER{from="%URLPARAM{"from" default="0"}%" to="%URLPARAM{"to"}%" encode="on" id="1"}%</textarea>
<textarea id="aftertext">%EXTRACTCHAPTER{after="%URLPARAM{"to"}%" encode="on" id="3"}%</textarea>
</noautolink>

We would like to see this improvement in EditChapterPlugin.

To the author of the Plugin - dear MichaelDaum - feel free to take the code and add what ever fits best.

-- AndreLichtsteiner - 25 May 2011

I see what you mean. Alas, the patch seems to lower the burden to hell even more. As far as I see you are trying to merge chapters on the client side to prevent the sub-optimal standard merge on the server side to create lots of ins and dels. Not sure if I get the patch right.

-- MichaelDaum - 25 Aug 2011

As I understood, EditChapterPlugin merges the parts beforetext, text and aftertext together on the client side.

This patch just updates beforetext and aftertext, in case:

• the topic has changed while an author is writing
• but the edited chapter remained unchanged

-- AndreLichtsteiner - 25 Aug 2011

I see. This might very well be a good idea to do. Or maybe this approach is flawed by design because - as you already said yourself - the chapter structure might be changed by an edit of beforetext. So fetching an up-to-date version before combining all three comes out strange. I can see this kind of chapter-based "merge" might be better than the bloody ins & dels.

Maybe a chapter-based merge (done on the server-side) is preferable even for the standard behavior: flag larger chunks of being in conflict rather than trying to merge prose per character.

What are your real-world experiences with it?

Still, this points out that there's a warning message missing like in normal edit where the user is informed about somebody else already editing the topic. This is the reason a merge as part of an edit-chapter is happening more often than during a normal edit.

-- MichaelDaum - 26 Aug 2011

We experience, that the users are happier the lesser they see the conflict warning message

But, you are right, having this chapter merge as a general feature would be nice. And an optional dialogue, informing about a successful merger would not hurt.

-- AndreLichtsteiner - 29 Aug 2011

For now I've added rest calls to properly lock/unlock in 4.10. Please have a check.

-- MichaelDaum - 29 Aug 2011

Having Chapter Edit in a modal dialogue looks nice. But it looks like that the modal dialogue with a NatEdit on top of Pattern Skin is not able to open another dialogue: link, image etc. We consider this a bug.

-- AndreLichtsteiner - 06 Sep 2011

All modal dialogs will be reworked to use jquery-ui.dialog instead of jquery.simplemodal. And these will be able to stack properly.

The initial bug report has been fixed. So I am closing this one.

-- MichaelDaum - 10 Jan 2012

Commenting is disabled while not logged in