The RCS files associated with topics are currently kept permanently checked out and locked by the apache user. This creates installation and general usage issues, that generate a lot of support requests and have to be solved by nasty scripts like RelockRCS. Not only that, it banjaxes simple installation automation.

Why?

Why do topics have to be kept checked out?

Why not leave them checked in, and only check them out when they have to be changed? Note that the very action of checking them out is an atomic locking operation that is a lot less risky than the current lockfiles approach,

It would be a lot simpler all round. And I (with my small brain) can't think of any reason why not.

-- CrawfordCurrie - 27 Sep 2004

Probably legacy reasons.

Actually, a save transaction is not just updating the RCS file, e.g. not just an atomic locking opration on that file. It involves some text manipulation (core and Plugins), updating the topic info, saving the .txt file, update the .txt,v file, adding logs, and adding changes info for recent changes.

The only reason to keep the lock is to discourage casual admins/programmers from updating the RCS file directly.

Automated update scripts should play by the rule and use the TWiki save mechanism to update an existing topic, preserving the existing topic history.

-- PeterThoeny - 28 Sep 2004

"Automated update scripts should play by the rule and use the TWiki save mechanism to update an existing topic, preserving the existing topic history." - agreed. The problem with keeping the locks is that those scripts have to run as the Apache user, which means that any update requires a step that can only be invoked from the browser (or a cron).

I guess an alternative would be to sudo those scripts to run as the webserver user, though I'm not sure if this works with RCS and less sure if it would work on non-Apache or Windows servers.

BTW this thought comes about because I was trying to get the plugins installer scripts in BuildContrib to automatically update ,v files during installation, to preserve local settings.

-- CrawfordCurrie - 28 Sep 2004

How about a poor man's CurlTool or CPAN:LWP, e.g. a simple home grown tool to update topics over http. We already have geturl and TWikiFuncModule with readTopicText and saveTopicText

-- PeterThoeny - 28 Sep 2004

Automated script have to go all the way througth TWiki to save a topic (check the comments in the code for PluginsInstaller in the cvs). That means calling TWiki::initialize with the proper parameters (creating a mock CGI helps).

The only workaround (that is used also by the UpdateTWiki script ) is to use rcs directly assuming that you're running as the same user as apache. Unfortunately, this will beak if the RcsLite alternative is being used or if we ever decide to have pluggable Store implementations.

-- RafaelAlvarez - 28 Sep 2004

Peter's idea is good, but it's a bit risky; it would be difficult to detect and correctly handle an error. Raf, it's not true that you have to go all the way through TWiki. If you have an already-correct topic (complete with meta-data) it can be checked in direct to RCS. I'm not advocating this, just saying it's possible.

• Crawford, that what I said -- RafaelAlvarez - 29 Sep 2004

BTW Peter, what you describe above is exactly how the "upload" target works in BuildContrib; it uses CPAN::LWP to upload to TWiki.org.

-- CrawfordCurrie - 28 Sep 2004

In PageCheckoutCheckinStrategy I also argued for having the files checked in by default and lock the RCS file while working. As a major change, I propose to check in the changed workspace copy only at the end of the edit, i.e. when the lock expires. Besides the advantages discussed above, switching from RCS to a different VCS would be very easy then. This opens the oportunity to go for ReadWriteOfflineWikis, because the VCS handles the grunt work of synchronisation and conflict resolution.

As to the user problems: if you adjust the group permissions, I do not see, why a different user in the proper group shouldn't be able to checkout/update/checkin stuff without resorting to HTTP hacks.

-- PeterKlausner 29.Sep.2004