Question

I want to use locking behavior similar to Ward Cunningham's wiki (c2.com). When two edits are being done on the same file, the first person who saves is allowed through. The second person is shown a message when tries to save, saying that someone else has already saved, so he will not be allowed to save. He will have to back out, edit the topic again (by re-opening it first, possibly in a new browser window), and save it. That way, he can still get access to what he typed when he hits back, and do a manual merge.

Is this possible in TWiki? It is a very useful feature to prevent people from overwriting each other's work accidentally. (I know about Edit Anyway, and that won't work in my context, as it does not guarantee that files won't be overwritten).

Environment

TWiki version:	TWikiRelease01Feb2003
TWiki plugins:	DefaultPlugin, EmptyPlugin, InterwikiPlugin
Server OS:
Web server:
Perl version:
Client OS:
Web Browser:

-- SomikRaha - 22 Mar 2004

Answer

You can't lose text in TWiki, unlike Ward's original Wiki. Breaking a lock and save a topic is not as bad as it sounds. You will create a new topic version. Anyone can recover a previous topic version and merge text. Go to the "More" screen and look at the raw text of a previous version.

The original spec of Ward's Wiki could be re-implemented in TWiki. IMO I do not see a big value in this.

-- PeterThoeny - 27 Mar 2004

The statement that TWiki cannot lose edits is completely false.

It is trivial to lose edits in the default configuration of TWiki as recommended and installed on TWiki.org:

Scenarios where data and edits are lost:

Scenario 1: Multiple Users Logging in as TWikiGuest

• User A logs in as TWikiGuest
• User A edits the page LetsLoseSomeEditsOne
• User B logs in as TWikiGuest
• User B edits the page LetsLoseSomeEditsOne within 60 minutes (lock time)
  • They delete User A's comments because they disagree with User A and didn't like their arrogance being pointed out

Result: The user cannot retrieve their changes. The reason for this is the simple fact that TWiki defaults to merging changes made by the same user -- TWiki defaults to losing edits .

Scenario 2: TWiki being used without Authentication

The majority of wikis are run in a non-authenticated mode. If a user tries to run TWiki in a non-authenticated environment, it is trivial to loose edits - all edits in this scenario appear to be owned by the guest user so this is a subset of the example above:

• User A edits the page LetsLoseSomeEditsTwo
• User B edits the page LetsLoseSomeEditsOne within 60 minutes (lock time)
  • They delete User A's comments because they disagree with User A and didn't like their arrogance being pointed out

Result: The user cannot retrieve their changes. The reason for this is the simple fact that TWiki defaults to merging changes made by the same user -- TWiki defaults to losing edits .

Scenario 3: TWiki being with Authentication in the Standard Setup - eg TWiki.org, and not using a shared login

Edits can be lost by users (eg on TWiki.org) trivially:

• User A logs in under their usual username - eg TWikiGuest
• They make a large number of edits on a page -- LetsLoseSomeEditsThree -- creating content, periodically saving working under the false assumption they're doing a checkpoint save.
• After the nth iteration they accidentally delete all of their edits and save, then their browser crashes

Result: The user cannot retrieve their changes. The reason for this is the simple fact that TWiki defaults to merging changes made by the same user -- TWiki defaults to losing edits .

Scenario 4: The site administrator (Or TWikiAdminGroup) Disagrees with an edit

The administrator of a site decides that edits are "wrong" somehow, for whatever reason. (Perhaps they look bad, someone posted spam, someone posted porn, whatever)

They decide to use the "admin only" replace revision command. This means that TWiki defaults to allow special users the ability to delete edits .

Result: Edits can be simply censored by the admin, for whatever reason.

All of these scenarios have happened in the past to TWiki users, and all (bar non-auth?) have happened to users on TWiki.org. The idea that TWiki cannot lose edits is completely false.

TWiki gets this wrong - defaults to losing edits and the response was wrong on very many levels.

-- TWikiGuest - 28 Mar 2004

Dear Guest, thank you for the detailed research. I was referring to a typical deployment of TWiki (as defined in the TWikiMission) where content does not get lost if a user breaks a lock and overwrites someone else's revision. The TWikiGuest account is typically not used in a corporate environment, so most your scenarios only apply marginally.

Since TWiki is open source and you seem to have a strong opinion on this subject you are free to enhance TWiki so that it fits your needs

-- PeterThoeny - 28 Mar 2004

This set of senarios is why I really don't see the point of not commiting changes every time save is hit.

-- SvenDowideit - 28 Mar 2004

If you want that, set the doKeepRevIfEditLock flag in TWiki.cfg to zero to force a new revision with each topic save.

-- PeterThoeny - 28 Mar 2004

Can you please explain Peter, why is doKeepRevIfEditLock the default? As it changes the semantics it'd be something that I'd want to consciously turn on rather than off.

-- MartinCleaver - 28 Mar 2004

in LockNotReleasedWhenPageSaved pth writes, "I believe we should keep the current spec for the distribution. Waiting for one hour is less disturbing then loosing text because someone hit the back button on a released topic. Loosing text when editing a topic that has no edit lock can be very confusing and can also anger people as happended in the past."

-- WillNorris - 28 Mar 2004

And Ward's wiki tackles this elegantly by not allowing you to save, if someone has already saved before you. That forces you to hit back, copy what you typed, reload the topic and do a merge.

-- SomikRaha - 12 Apr 2004

We've been running TWiki for nearly 9 months now, our users are predominantly "non-technical people". The current locking system poses a lot of problems, it does not appear to be user friendly. "IT people" on the other hand like it the way it is. From the feedback our "non-technical users" gave us we gathered that they prefer the Wikipedia-mechanism: first save is allowed through, second save gets a message and a new edit box (with the new version of the text). The users original edit box is preserved and displayed below the new edit box on the same page. There's no need to use the back button or anything, you simply copy/paste your text into the new edit box. You can't lose text this way and appears to be more user friendly than the TWiki system.

Actually, our experience so far has shown that TWiki is just two major drawbacks - the login and the locking mechanism.

-- ChristianKohl - 09 Jun 2004

PeterThoeny wrote:
You can't loose text in TWiki, unlike Ward's original Wiki. Breaking a lock and save a topic is not as bad as it sounds. You will create a new topic version. Anyone can recover a previous topic version and merge text. Go to the "More" screen and look at the raw text of a previous version. The original spec of Ward's Wiki could be re-implemented in TWiki. IMO I do not see a big value in this.

Wards's wiki does not loose text - by pressing back, its easy to pick up the text and merge it with the existing copy. That is way more natural than mucking with version control.

The usability issue here is that if you do break a lock, you end up overwriting existing text, which you really don't want to do. You'd then have to look at the older versions if you were inclined to, and do a merge.

Ward's wiki combines this into one step. You cannot save a file if it has been saved already after you started editing it. The simplicity of it is so apparent, like so many things that Ward does.

I know that this involves some re-evaluation of the internals of TWiki. I am hoping you will be convinced of the benefit.

-- SomikRaha - 06 Apr 2004

Scenario 1 & 2 don't apply for an intranet TWiki.

Scenario 3 is a feature IMHO. If you open multiple edit windows, the latest save wins. What else would be more intuitive? Special about TWiki is, that it allows you to store away every single save with doKeepRevIfEditLock. (I do not recommend this, because it really ruins my beloved diffs. (Hmm. Might be a change request: show only diffs between authors | full days?))

Scenario 4: Unless it's transferred away from the server immediately, your admin has full control. You can make it a bit harder, but never prevent it. That's why e.g. banks track critical transactions on WORMs. You can also do that with TWiki if you really need that level of accountability IMHO, it should be easy for a wiki admin to undo things. I.e., it's a feature, not a bug.

Usability-wise, I'd prefer Wikipedia's approach. TWiki's lock warning up-front scares away non-technical users. And the overwritten author is not notified automatically. Ward's back, copy, back, re-open, edit & paste cycle isn't exactly for non-techies either.

-- PeterKlausner - 13 Jun 2004