create new tag
, view all tags
The file locking mechanism needs to be improved. Several people at my site have found that at times when changes are being made to pages by multiple people, the file locking (or is it really only a warning mechanism?) does not convey enough information or protection. They get a warning and are then left with the choice of ignoring the warning or tracking down the listed user and verifying that they aren't acually editing the page anymore.

Assuming only an RCS back end for now, the pages should always be checked in unlocked and only checked out locked when someone clicks on the edit link. I don't know if RCS allows it (rlog implies that this can work) but the real user should have their name applied to the checkout so that nobody else can modify the file until it is checked in. Saving the page would check in the file unlocked, leaving the file immediatly available for another user to edit.

This of course will cause problems when users click on the back key of the browser to fix that one typo that they found after saving the page. Can the edit (and possibly the preview) page be configured as non-cacheable in its HTML header, so that the user is forced to eithe re-post the edit or go forward to a new edit to checkout the file once again? This might force one way trips through the web pages with enforced blocks to backing up through an edit session to make sure that the files were always checked in or out in a proper state.

I'm not sure if these issues would automagically be solved for people using CVS as per the discussion in TWikiWithCVS .

-- JohnAltstadt - 07 Apr 2000

After a little more consideration, it would probably be best if the preview page was the one non-cachable. That way people could bounce back and forth between the preview and edit, but once the file was saved it would be impossible to go back to the preview and hence back to the edit.

-- JohnAltstadt - 07 Apr 2000

I'm gonna keep flogging this one for a bit.

Yet another way to handle this is to add a small amount of javascript so that:

  1. the edit link opens a browser edit window
  2. the save button closes the browser edit window, and
  3. sends a refresh signal to the original window

This lets people continue to use the back button the normal way and enforces procedures that checkin and checkout the files.

The file owner needs to be able to back out of the changes with a new button that discards the changes, checks the file back in, and closes the edit window. In addition, the file owner should be able to re-open the file for edit if the browser crashes (or the user closes the window) with the choice to discard the previous changes (i.e. checkout the file over top of the current file) or continue from where the file was left. This also allows a user to deal with the issues discussed in the AutoSave topic.

-- JohnAltstadt - 07 Apr 2000

You are right, it is more a warning mechanism then a file locking one. Trust among contributors is a fundamental base for many Wiki communities, that's why I believe that a warning mechanism is more adequate. Of corse, this does not fit a typical software development group which is used to check-out/lock, edit, check-in/unlock cycles.

As you said, doing a lock when someone follows the edit link and performing an unlock on save has it's problems in a web environment. There are other problems in addition to the ones you stated:

  • User edits a topic just to see how the raw text looks like, then goes back to the topic view. Topic is no locked indefinitely, unless some expiring mechanism is put in place. Same case if user quits the browser or closes the window showing a page in edit mode, or if the browser crashes.
  • User saves a topic but decides to make more changes after - lets say 5 minutes. Topic is now unlocked and might be locked by someone else.
  • Even if the preview page is set be non-cacheable it is possible to jump back from view directly to edit, by bypassing preview (browser back menu).

Also, I prefer to keep TWiki's requirement as low as possible. It is nice to take advantage of JavaScript where appropriate, but I prefer not to depend on it.

For all of these reasons I chose the one hour 'soft-locking' or warning mechanism which is a nice compromise in a web environment. I'd rather stick to the current implementation.

-- PeterThoeny - 09 Apr 2000

After another week of use I should add some more comments to this.

  1. we have gone from 1 user to ~150 users over the course of two weeks, so there is a lot of activity right now
  2. we are a very heterogeneous mix of software and hardware engineers, PHBs, sales people, admin assistants, and receptionists
  3. we have set up two parallel TWikis with different authentication groups:
    • one TWiki is restricted to R&D use, the other is for general use
    • the Main and Know webs, templates, much of pub, and most of bin are identical in each TWiki by virtue of softlinks (aren't they a great thing? aren't you glad Microsoft invented them?) ....Oh my gosh. They are a trip, aren't they? Unbelievable. --Main.KevinKinnell 15 Apr 2000
    • the general TWiki has some very volatile information that is updated daily by admin assistants

So far the only complaints I have heard more than once are about the file "locking" mechanism. People just don't want to have to phone each other to find out if they are finished with an edit. One user pointed out that if he is working at home, there is no way for him to phone out or someone else to phone in because that is his link to work.

A couple of people wanted to have the edit link open up a new window because they always need to surf around to collect links while editing. This was relatively easy to hack in by changing the edit, create, and ? links in view and wiki.pm to open in target="edit". This is heading in the direction I talked about earlier.

You raise some valid points above.

  1. Trust among contributors is a fundamental base...
    • Unfortunately trust doesn't prevent simple errors.
  2. User edits a topic just to see how the raw text looks like...
    • Having a separate edit window open means that the window has to be closed. The close event can trigger a checkin either via a close button or possibly via some javascript.
    • If the user has accidentally locked a file, then the user can can unlock it again by hitting the edit and close links. This is just a phone call away (which is the current situation) or else someone can login as that user and do the same thing if the user can't be reached in a reasonable amount of time.
  3. User saves a topic but decides to make more changes after...
    • Tough, live with it. Software developers have dealt with this for decades. This is more acceptable to the non-tech users who are currently far more likely to see a big scary warning message if it hangs around for an hour. If there is a collision of this sort, then you can always phone the person holding the lock (once again, this is the current situation). An administrator can always break the lock if required.
  4. Even if the preview page is set be non-cacheable...
    • Opening a new window and then destroying it upon page save as described above prevents this.
  5. ... JavaScript where appropriate, but I prefer not to depend on it.
    • I would rather turn javascript off in all my browsers but I can't because the rest of the web (including our intranet) uses it.
    • Fairly trivial use of JS to close and send refresh messages to windows is a reasonable use.

Thinking a little more about what little I know about CVS, it seems like CVS would solve the majority of these problems since file locking wouldn't be required. I would migrate our archive (or just blow it away and start over) in an instant if CVS was supported. Unfortunately the easiest way of coding this would create a different behaviour depending on the archival back-end used. Or is that a good thing? smile

-- JohnAltstadt - 14 Apr 2000

How about a "done" button next to save? It would do a save, and then release the lock. If there were a page like the web stats page, where broken locks could be viewed, the users would get a feel for who reliably uses the "done" button and who doesn't, and a feel for who indiscrimanently breaks locks and who doesn't. Social pressures would make it work, probably much more effectively than almost any pure technology solution. It also is back-end independent, and much more friendly to non-JavaScript enabled browsers (I'm a big Lynx fan myself, and TWiki is a pain to edit with Lynx but it's still possible. Add too much stuff that relies on JavaScript and that won't be the case anymore.)

-- KevinKinnell - 15 Apr 2000

Oddly enough, there I was trying to add thoughts to the BetterFileLocking page and what do I find? Someone has the page locked..the last guy who submitted something no less..:):)

So to revisit the problem...in my own views...

It seems to me that we are really starting to struggle with an issue that has been a problem with teamwork documentation forever. We are trying to figure out a easy way to do what Teamware (I think that was it) and a host of other products have tried to fix. The onus of this problem rests solely on what revision control system we use. Strict file locking is not the solution. It is a short term solution for small teams, but when you have ten others trying to edit the same page at the same time, making minor tweaks here and there, no amount of file locking is going solve this problem.

These are the issues that have faced distributed code developers as well, and the environment CVS was created to address. Research into distributed operating systems and distributed file systems have kinda solved these problems with some very nifty techniques. But for the common man, CVS is what we have.

I guess to wrap up the problem...again in my own words..

We are trying to implement or use an existing technology to allow us to edit a file on a remote file system, maintaining file integrity and making it as easy for the user as possible.

-- JesseMcConnell - 15 Apr 2000

Better file locking is an issue for certain environments, currently it is no issue for our deployment at Wind River. But I see the needs. The best (but complex) solution is probably a TWikiWithCVS. This must be carefully designed.

As a simple workaround to the file locking problem you could simply reduce the lock time to - say - 10 minutes after a topic save. I would recommend to leave the edit and preview lock time at one hour, this is to prevent simultaneous edits. The short lock time after an edit is a compromize between "oops forgot something" and "heck I want to add my 2c". To set the save lock time to 10 minutes you could use the current time minus 50*60 seconds.

Another solution to the file locking problem is to add a new feature to add text to a current topic as described in ThreadedDiscussions. This would eliminate edit contention all together for "threaded" discussions in Wiki (actually not really threaded, because all text is on the same page for easy scrolling)

-- PeterThoeny - 19 Apr 2000

File locking can be eliminated by following the CVS paradigm .

This does not require you actually use CVS as the back-end, in fact that may actually make it slightly harder. See my expanded explanation in TWikiWithCVS.

-- MathewBoorman - 24 Apr 2000

It would be helpful if the lock is optionally released whenever the user saves a page. A second button, "Save Changes & Unlock" would let users voluntarily say they are done editing.

-- DaveHolcombe - 05 Jul 2000

The file locking issue turned up at work (Wind River). KevinKinnell's idea of a "done" button next to save is a quick solution, but users need to be aware of what it does. I did a quick implementation on the TWiki Alpha installation at http://TWiki.SourceForge.net/cgi-bin/a/bin/view/Test/ , by adding an "Unlock topic" checkbox next to the [ Save Changes ] button. Let me know what you think. I will commit the changes into CVS if acceptable.

We even could introduce a new user level variable that determines the default state of the checkbox.

-- PeterThoeny - 05 Jul 2000

I liked it, but I'm a little leery of the browser-history issue. Is there some way to add a Meta to the page delivered by the save button? I was thinking of save the topic, then reload the ../edit/TopicName to replace it in the cache, but put a refresh Meta tag in the header to redirect to ../view... in one second. If it could be made to work, there would never be a problem with users replacing their own edits with the previous version. This would save the sitemaster a lot of headaches.

-- KevinKinnell - 07 Jul 2000

I changed TWiki alpha and commited changes of new checkbox to CVS.

I leave the TopicClassification as FeatureBrainstorming because there are other issues left.

-- PeterThoeny - 07 Jul 2000
-- PeterThoeny - 15 Jul 2000 (restored from backup)

I have some problems with making people manually release the lock via a Done button or Unlock checkbox. It is bad enough having such a fundamental idea of locking exposed to the users without asking that users manipulate the locks as well.

I have spent some time browsing through the JavaScript reference to come up with a pair of simple pages that can be used to illustrate the point I tried to make at the beginning of this thread. Unfortunately using JavaScript eliminates this method for those people using lynx and similar browsers, but we can probably assume that people who choose to use textmode browsers are smart enough that they don't have a problem dealing with file locks manually.

The file test1.html is a sample page with an edit page or create new page link on it. Hitting this link pops up a new window that is devoted to editing the page. This edit page has several controls on it that need to affect the lock file: the two HTML buttons Save and Abort , and the regular browser buttons.

I have put in alert boxes to replace the real TWiki CGI scripts, and delay loops so that you can see the order of when the lock files need to be created and destroyed. I don't know Perl well enough to carry through with the scripting side (on the other hand, if TWiki was re-written in PHP... :-).

The string WEB_TOPIC in test1.html would be replaced with the concatenated TWiki variables %WEB%_%TOPIC% so that users could be editing multiple pages simultaneously.

Play around with the pages to see if this makes sense. You need to have JavaScript enabled to try this. Note that there are some very short windows in this demonstration that could create race conditions in a real implementation.

-- JohnAltstadt - 22 Jul 2000

Just a note once I've got PackageTWikiStore near completed, it should be easy to create some sort of maildir type while-in-edit-mode topic file with some short term locking and merge logic to show conflicted saved-during-my-edit issues.

I could probably do it now (*), but I figure PackageTWikiStore is more important.

(*) In fact much easy to do than my attempted a TWikiWithCVS, especially if I use some external application like diff3.

-- NicholasLee - 02 Aug 2000

John's comment in ReleaseEditLockByDefault prompted me to revisit this topic. The attached sample HTML files basically work but it would raise the RequiredEnvironmentForTWiki be requiring JavaScript. Currently it has "JavaScript can be used, but only as a feature enhancement that degrades gracefully for non JavaScript enabled browsers." TWiki already does use JavaScript at a few places, but you can operate TWiki also without JavaScript, or with JavaScript disabled.

I am not so sure if it is a good idea to raise the required environment for all. What we could consider is a user preference setting, so that the user can choose a pop up style edit window that requires JavaScript...

One thing I noticed with the sample HTML files is that the release lock dialog does not come up when you close the window. Using Netscape 4.7 something.

-- PeterThoeny - 30 Mar 2001

When the user saves an edit but the topic has been independently changed, we could warn him that this has happened, and present the result of using diff3 to merge the changes. He could then go through the preview/edit/cancel/save process all over again, starting with the merged version.

  • ColasNahaboo - 11 Apr 2001: yep, just checking if there is still a valid lock when we save (belonging to saver and less than 1 hour ago), and if no, save, and warn that we have overriden another change and that manual merge should be done (should we mail the overriden guy also?). for manual merge, the ViewRawPage addition is invaluable, as well as avoiding having to lock (edit) to see page source...

-- HendrikBoom - 31 Mar 2001

For now, in my installation, to alleviate this problem I made the following changes:

What would be nice now is a way to tell TWiki that you want to be emailed when the edit lock goes off when being presented with the page that somebody is editing this page...

-- ColasNahaboo - 02 Apr 2001

Peter, you mention changing the file locking time to 10 minutes or so. How do you do that? I haven't tracked it down by searching twiki.org and it's not in the preferences anywhere. Is a perl change in order?

-- JoelSumner - 03 Apr 2003

Edit config file: lib/TWiki.cfg , see variable $editLockTime = "600"; # 600 sec = 10 minutes.

-- PeterMasiar - 04 Apr 2003

Back in April 2000 Peter mentioned having a different lock time after a save, but as far as I can tell, this has never been implemented. I have found a very crude way to implement this, but I am not sure exactly which of the places where locking is done should have the alternative timeout. What I did was to add a variable $saveLockTime in lib/Twiki.cfg (which I set to 600, i.e. 10min). I then changed $topicHandler->setLock( ! $doUnlock ) to $topicHandler->setLock( ! $doUnlock && $TWiki::saveLockTime) in saveNew in lib/TWiki/Store.pm. (This is where I am not sure if that is the right set of places, and the crudeness of the change becomes clear.) The effect is to pass a number of seconds to lock rather than the "1" that was passed before (and still is from elsewhere). The other thing to do is to edit setLock in lib/TWiki/Store/RcsFile.pm to deal with the number:

        my $lockTime = time();
        if ($lock>1) {
            $lockTime -= $TWiki::editLockTime - $lock;
        $self->_saveFile( $lockFilename, "$userName\n$lockTime" );    

Crude, but it seems to work so far, and with luck will let people cooperate on pages without introducing too much of a risk. If anyone has an opinion on this, I would be very glad to hear it.

-- OwenRees - 10 Sep 2003

Topic attachments
I Attachment History Action Size Date Who Comment
HTMLhtml test1.html   manage 0.5 K 2000-07-22 - 22:39 JohnAltstadt sample TWiki page with an edit link
HTMLhtml test2.html   manage 0.6 K 2000-07-22 - 22:40 JohnAltstadt sample TWiki page being edited
Edit | Attach | Watch | Print version | History: r23 < r22 < r21 < r20 < r19 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r23 - 2008-08-24 - TWikiJanitor
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.