Question

How can I turn off revisioning for a specific page/topic? Do I have to modify the registration libs or is there a directive I can put on a page?

Specifically, I don't want my TWikiUsers page to have 10K+ revisions.

Thanks for any info. I did this through a code change in TWiki3, it was a method parameter that could be passed in to the AddToTWikiUserPage (something like that). I didn't spot where this was in T4.

Environment

-- EricHanson - 27 Jul 2006

Answer

If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.

AFAIK there is no such feature.

Perhaps you would like to contribute it?

-- MartinCleaver - 27 Jul 2006

I can see a need for avoiding revisons for large attachments (such as CD images), but plain text does not eat much space. What is the problem with 10K revisions on a topic text?

-- PeterThoeny - 29 Jul 2006

You always can reset all revisions by removing *,v files on the server. Should this 'feature' be available to TWikiAdminGroup members via web?

-- FranzJosefSilli - 30 Jul 2006

There are some thoughts on different backends / stores for different TWikis / webs / topics; some of these stores could be without revisioning.

I think some initial code is in DEVELOP, but we are not there yet.

-- SteffenPoulsen - 30 Jul 2006

What would make more sense it to have (out of band) metadata that specifies such things as:

• How many (if any) revisions are kept
• The kind of markup used in this topic, or
• The nature of the contnet of this topic, markup, PDF, RTF etc.

-- AntonAylward - 01 Aug 2006

Sounds like a good idea.

-- SteffenPoulsen - 01 Aug 2006

I was primarly wondering if this is still a flag option like it was in TWiki3?

Is there documentation regarding the changes made to the code? I am trying to upgrade some scripts that we made but am having trouble finding the new TWiki4 equivilants, such as the function TWiki::isWebName.

-- EricHanson - 03 Aug 2006

Seems wierd answering my own question, but if this helps anyone else, cool.

So in TWiki::Users::TWikiUserMapping there is a new method addUserToMapping that does some stuff then makes a call: $store->saveTopic

This method takes some options:

* =$options= - Ref to hash of options
=$options= may include:
| =dontlog= | don't log this change in twiki log |

I believe an inlined hash would be saveTopic( ..., {dontlog=>1});

Its nice to see TWiki coding in a direction that will allow future growth by using a hash for arguments but it would be nice to see it go further such as CGI.pm, in which all arguments can be explicity set by doing:

foo( webName=>"TwikiFun", webOwner=>"Nemo" );

-- EricHanson - 03 Aug 2006

If you restrict your activities to the published APIs (TWiki::Func), there should be no problem. If you find that there are core functions that you need to use from extensions, then ask (in Codev) for them to be published. If you call unpublished core functions directly, you can expect to come unstuck, I'm afraid. Having said that, isWebName are still there, just renamed to isValidWebName (for consistency with other "isValid" functions, and to avoid confusion with webExists ).

On named parameters; there is a strong case for named parameters for methods published via the TWiki::Func interface, and some of the more complex internal interfaces such as that to the Search module. Using named parameters everywhere would be rather inefficient (a hash lookup for each parameter ref!) so will not be done any time soon. My general rule of thumb is to use named parameters only where an interface if generic and widely used, and then only where there are optional parameters, and then only when there would be more than half a dozen parameters to the method otherwise.

w.r.t your original question; selective disabling of versioning is not currently available, and I had never considered it as a requirement for general topics. For the TWikiUsers page only, you can change the call to saveTopic in TWikiUserMapping.pm to a call to repRev. This will replace the latest rev of the topic with your new rev. Though like Peter, I can't see why you would want to do this (the history is really pretty small for a text topic)

-- CrawfordCurrie - 06 Aug 2006