tags:

views:

469

answers:

7

If two users edit the same wiki topic, what methods have been used in wikis (or in similar collaborative editing software) to merge the second user's edits with the first?

I'd like a solution that:

  • doesn't require locking
  • doesn't lose any additions to the page.
  • It may add extra "boilerplate" text to indicate where differing changes were made.

(I'm interested in a solution that could be used to implement this uservoice idea for stack overflow.)

A: 

You can write a "lock" in an other database table with the id of the user and the time and delete the "lock" (that isn't a real lock for those who do not understand) when the person save or after x minute.

This way, when someone try to edit and someone already doing it. A message can appear with the time remaining OR by just telling that someone else is currently editing the post.

Daok
Warning that another user is editing is good. TWiki does indeed do something like this just so it can warn user that a topic is being edited, it's just that it still allows them to edit and save and will try to merge the edits. I'm really looking for solutions that attempt to merge the two edits.
Sam Hasler
+2  A: 

My experience with most Wiki software (e.g. MediaWiki) is that it tracks the version of the document you are editing. If the document changes during your time editing, your change is rejected and you are prompted to perform a manual merge.

64BitBob
I suppose that's one alternative. I'm really looking for a solution that merges the two edits automatically. Does MediaWiki in any way facilitate the manual merge?
Sam Hasler
MediaWiki shows you the diffs between your version and the last stored version along with the full text of both versions. Presumably, this helps you resolve the conflict manually. Depending on the edit, I imagine it is occasionally easier to copy your work to notepad and start over.
64BitBob
A: 

Well, you could use a merging algorithm, like that used by source control software. You'd probably want to make it check for changes at the paragraph level, to help maintain readability.

If there was a potential conflict (e.g. two users editing the same paragraph), you would probably need to simply present both versions with boilerplate text and/or notify the second and subsequent submitters that the contents of their post may have changed from what they submitted.

AaronSieb
+4  A: 

TWiki automatically merges Simultaneous Edits.

TWiki allows multiple simultaneous edits of the same topic, and then merges the different changes automatically. You probably won't even notice this happening unless there is a conflict that cannot be merged automatically. In this case, you may see TWiki inserting "change marks" into the text to highlight conflicts between your edits and another person's. These change marks are only used if you edit the same part of a topic as someone else, and they indicate what the text used to look like, what the other person's edits were, and what your edits were.

TWiki will warn if you attempt to edit a topic that someone else is editing. It will also warn if a merge was required during a save.

There was also some documentation from that feature being developed detailing how it would behave.

The basic principles I used in coding up the mergeing algorithm were:

  1. If it's possible to merge without using conflict markers, do so.
  2. If it's possible to merge using conflict markers, do so.
  3. If it's not possible to merge, then the most recent checkin wins.

It's worth noting that TWiki has a similar feature to Stack Overflow for collapsing subsequent revisions by the same user within a certain time limit and this caused a bug when happening in conjunction with a merge.

  1. User A edits topic
  2. User A saves rev N
  3. User B edits topic, picks up rev N
  4. User A edits topic again, picks up rev N
  5. User A saves changes; save sees that the change is within the ReplceIfEditiedWithin? window, so does not increment the rev number
  6. User B saves, code sees that the rev number on disc has not changed since they started editing so doesn't detect a need to merge.

Also worth noting is that TWiki will warn the second user that the topic is being edited:

So I invented the concept of "leases". When a topic is edited, a lease is taken on the topic for a fixed period of time (default 1h). If someone else tries to edit, they are told that there is already a lease on the topic, but that doesn't stop them from editing. It isn't a lock, it's just a way of advising them. Mergeing is still the prime resolution mechanism; the lease is purely advisory. If a user - or a plugin - chooses to back away from a topic because someone has a lease out on it, well, that's up to the plugin.

The descriptive comment in TWiki.cfg is as follows:

   # When a topic is edited, the user takes a "lease" on that topic.
   # If another user tries to also edit the topic while the lease
   # is still active, they will get a warning. The warning text will
   # be different depending on whether the lease has "expired" or
   # not i.e. if it was taken out more than LeaseLength seconds ago.

note that the lease terminology is only for developers, not end users.

Sam Hasler
A: 

Well now, I think that that would be a terrible, terrible idea. Let's be honest: merging is pretty dicey in code, and that at least has elements that might be isolated. Don't do this - human intelligence will always be better. Instead you are trying to replace it with an automatic solution that can result in output that is not sane, for no benefit.

Marcin
The TWiki solution is in use today in hundreds of TWiki installations, so I doubt that's the case. Most of the time it's able to merge without conflict and when it's not it makes clear what's happened and makes all the content available for editing without having to look at a separate diff.
Sam Hasler
Simultaneous edits aren't common on StackOverflow but they can be tiresome to fix when they happen. (I've seen it on the Unofficial FAQ.) The biggest issue at the moment is that unless you pay attention you won't realise it's happened. Something like this would at least force you to deal with it.
Sam Hasler
I don't think you understand what a conflict is here: there is a whole space of changes that would not be a conflict to any kind of diff algorithm that is a conflict in the meaning of an article.By using diff, you are not forcing people to deal with conflicts, but masking them.
Marcin
Atually, after reading the TWiki page more fully, I see that it does handle the situation where it would be impossible to merge by just saving the most recent edit. However, whenever it can merge the two edits it would, with change markers if needed. I think that's the best of both worlds.
Sam Hasler
A: 

In researching the TWiki answer I also stumbled across SynchroEdit which appears to be a SubEthaEdit style browser-based simultaneous multiuser editor. It looks like it may have been abandoned around September 2007, but there's source code available for download.

Sam Hasler
A: 

For documentation sake: DokuWiki places a 15 minutes lock on edited pages, which gets renewed whenever you preview your edits (ie. 15 minutes from your preview or edit start).

Cd-MaN