Question

If I open multiple browsers, and attempt multiple concurrent edits, all traces of some of my edits are lost. This happened to me on a real project and it's very embarrassing because a significant amount of someone else's work was lost.

To reproduce:

Open browser window A, browser window B.

Point A at a new topic. Add a line

FOO -- 1

to the topic. Preview, save. Edit it again.

Point browser window B at that topic. Add a line

BAR -- 2

to the topic. Preview, save, view, everything looks good.

In browser window A, which still has Edit showing only FOO -- 1, add

BAZ -- 3

and preview/save.

All traces of BAR -- 2 are gone---in the diffs, in RCS, everywhere!

I don't understand this. There is a straightforward fix to this and I'd be happy to present and discuss it, but at the moment I don't know what to do. I've moved collaboration back to the mailing list for the moment.

[Note that I am running Twiki unauthenticated to keep things simple for now.]

• TWiki version: TWiki20010901
• Web server: Apache
• Server OS: Linux 6.2
• Web browser: IE 5.5
• Client OS: Windows NT

[What I expected Twiki to do is to remember the RCS version number it presented to me for editing, and compare that against the current RCS version number on the server, and if there is a mismatch, present the diffs back to me and tell me that someone else made a change while I had been editing it.]

More info: the RCS version number does not appear to be incrementing on each change. ???

Okay, I found out what the problem is: twiki uses soft locks and assumes each user knows what he is doing. So you must use authentication, and you have to personally be careful of keeping multiple browser windows open. Why can't twiki just remember the RCS version checked out and present a diff if there was a concurrent change? That's simple to implement and would solve the whole problem; no need for soft locks or anything. The only tradeoff is people who edit the file for a long time may have to deal with some merges. So you learn to do quick edits, just like in cvs or any other source control system.

As it currently works, I have to get all my users (around the world, who are afraid of the Edit button, let alone authentication!) to register, and then deal with the locking issues.

Heck, I've got the source. Maybe I'll hack it into what I need. It's only Perl.

-- TomRokicki - 05 Nov 2001

Answer

I am not a TWiki expert (by any means), but I think one related point re:

"More info: the RCS version number does not appear to be incrementing on each change. ???"

is that TWiki includes a 60 minute (by default) editing window -- edits made by the same person within 60 minutes of a prior edit are rolled into the previous edit (i.e., the RCS version number is not incremented).

I suspect that this was done at least partially to avoid excessive incrementing of the revision number when an editor saves his work multiple times during one editing session.

In general, your approach of providing a warning sounds useful. I (or preferably someone more knowledgable) should think about how that affects the whole user experience. I do know that, at times, I keep browser windows open for a long time and use the browser back button to re-edit a page -- I guess there is a chance that I will step on somebody else's edit one day (if I haven't already).

-- RandyKramer - 06 Nov 2001

I agree that this sounds like a problem. At the very least it needs to be documented so I've added it as an issue for this release. A proper fix such as a merge that you suggest would be preferable so I'd encourage you to take a look at an implementation.

-- MartinCleaver - 06 Nov 2001

One solution that preserves the small-changes model is to go ahead and use RCS version numbers for each and every change, and have the Twiki Perl code decide which of these changes to present as combined changes in the UI. In this case at the bottom it might say something like

1.23 --> 1.19 --> 1.15

(with some missing numbers for the incremental changes) but that should be just fine.

But frankly, I prefer to see the intervening edits as well. One philosophical question: is Twiki intended to be usable in a way where there is no authentication; that is, everyone logs in as the same user? If yes, then I think we need to see every edit separately.

Maybe a simple configuration switch to disable the soft edit stuff and force version number checks is what we want; in this case, when someone turns on this flag, you'll see every change, including all the little ones, but you will be able to detect when someone is about to obliterate a change.

-- TomRokicki - 05 Nov 2001

I agree with needing the force version change option. I reckon that the whole bottom bar at the bottom should be configurable and include a Save No Preview and Force New Version check-box.

-- MartinCleaver - 07 Nov 2001

> [Note that I am running Twiki unauthenticated to keep things
> simple for now.]

The TWiki is not designed to be used extensively without authenticating the users. TWiki is targeting the corporate Intranet world, users are typically authenticated in that environment (audit trail).

"Save No Preview" and "Force New Version" check-box is good feedback. Check if there is already an entry in the Codev web.

-- PeterThoeny - 10 Nov 2001