• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

I was looking through http://twiki.org/cgi-bin/view/Codev/DakarReleaseNotes for a summary of what might have changed with TWiki's RCS locks.

I moved a web from an old Cairo install held in unix user 'usera' to a new Dakar install held in unix user 'userb'.

Doing so caused TWiki to barf on save (can't get lock) and because the save failed and I was using kupu, I lost my changes.

New topic created using the Dakar install work fine, its the old one that fail. I think that the topics need relocking or maybe just unlocking. I'm not sure which.

In http://twiki.org/cgi-bin/view/Support/RelockRcsOnDakar it was suggested the admin use the ghastly manual procedure.

Perhaps UpgradeTWiki would help - it seems to apply to the whole wiki though, not just the current web.

It would be better if any unlock/relock is done on the fly, like upgrade category tables


The only way this can happen (I think) is if the user who has the files locked in the old web is not the user who is running apache in the Dakar install. You don't give the complete error message so I can't tell for sure.

Yep, i just checked;

  1. Created a topic in a shared web using Cairo
  2. Edited and saved it using Dakar code (same apache server, therefore same user)

and it worked fine. Suggest you document this in a topic on TWiki.org.

CC

Thanks for looking at this - the one thing that is different to your diagnostic set up is that my unix user changed during the process - it was usera and is now userb.

MC

I've deleted some of my points that were irrelevant.

I tried breaking the .txt file lock with rcs -u - it seems to work now for me, not yet sure whether there are other ramifications.

Editing and saving seems to not RCS relock the files - I assume this means Dakar does not leave the files locked? If so that would be a change.

MC

The error message was:

During save of WebName.AdslModem an error was found by the version control system. Please notify your TWiki administrator.

=Failed to get a lock, RCS: /usr/bin/rcs -q -l %FILENAME|F% failed: =

Go back in your browser and save your changes locally. 

MC

The following is how I bulk unlocked a folder:

yes | rcs -I -u -M *,v 

As I say, it seems Dakar no longer locks but it does require that the topic not be locked. Does anyone think that it would not be preferable that requirement disappears?

MC

Locks are used by RCS to make file operations atomic. If a topic is locked by someone else, then it would be extremely bad practice to simply break that lock! The lock is a clear indicator that something is worng, and should not be ignored.

Also, it's a very rare case. I can't see a benefit to adding code to break RCS locks.

CC

Not sure we want to break the locks like I did. Maybe we ought bulk unstrict the files?

TWiki:Codev.RcsNonStrictLocking and TWiki:Codev.KeepRcsFilesUnlocked were the references I was looking for. Cairo keeps the files locked - Dakar does not. If you move the files between Cairo & Dakar then Dakar barfs when it sees the RCS files locked. At minimum we ought document this.

MC

Please feel free to document it on twiki.org. I don't think doc is needed in the release.

CC

Done: TWiki:Codev.TWikiRcsUser

Thanks very much to Colas and Crawford for your help.

MC

ItemTemplate
Summary Should Cairo strict locks be softened when edited by Dakar?
ReportedBy MartinCleaver
Codebase

SVN Range 8057-
AppliesTo Engine
Component

Priority Normal
CurrentState No Action Required
WaitingFor

Edit | Attach | Watch | Print version | History: r9 < r8 < r7 < r6 < r5 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r9 - 2006-01-07 - MartinCleaver
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback