create new tag
, view all tags
At the moment, TWiki keeps RCS files permanently locked (RCS locked, not TWiki locked).

This causes problems for the administrator who wants to manage TWiki data files outside of TWiki, and has been the source of a number of bugs. It also makes it difficult for installer and upgrade scripts, that have to finagle their way around these locks in order to check in updated topics.

It has never been clear to me why TWiki keeps data files locked. The file history can be perfectly happily maintained if the .txt file is just a read-only copy of the head of the versions in the ,v file. I can't see any reason for maintaining a lock.

Unless someone can educate me otherwise, I propose that we change this so that TWiki's RCSLite and RCSWrap implementations never lock files. Further I propose that the permissions on TWiki data files can be selected in the TWiki configuration.

This can be done in such a way as to make all current data fully compatible with a DEVELOP TWiki. However once that data has been written with DEVELOP, it would have to be run through RelockRcsFiles before it could be used with an older version of TWiki.

-- CrawfordCurrie - 22 Jan 2005

I also could never find the reason why the files were locked - though I think that when you unlock them, rcs removed the .txt file...

I still think you are right, and only doing it will tell us otherwise

-- SvenDowideit - 22 Jan 2005

The only reason to keep the RCS files locked I can think of is to make it harder for other programs to manipulate them directly!

Fiddling directly with RCS files to manipulate TWiki content is not recommented since it circumvents other things TWiki does (such as .changes update) and Plugins might do (such as updating cache data). Developping a CLI is a better approach.

Since the locks impose some issues during upgrade we can get away with them. However, I think it is very important not to use an external utility to fix the lock in case there is one. That is, the TWiki storage can assume that there is no lock (for performance) and unlock on failure (if there was a lock). That way it is possible to upgrade older installations / drop some files from backups without any issues. This is in line with the TWikiMission.

-- PeterThoeny - 23 Jan 2005

Totally agree about the CLI point. A CLI would also allow abstraction of the Store. However a successful CLI would have to be done so that a non-apache user could lock/unlock RCS files, which isn't currently possible.

OK, let's try DEVELOP without locks, and see if we can pick up on any issues. Note that most store operations are already atomic (courtesy of the changes done in ReleaseLocksOnSave).

-- CrawfordCurrie - 23 Jan 2005

OK, it's there to try, r3639. That should allow other users (those with write permission, anyway) to use TWiki::Store functions to save topics without having to mess about with locks.

-- CrawfordCurrie - 17 Feb 2005

Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r7 - 2005-02-17 - CrawfordCurrie
  • 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-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.