Basically if the $doKeepRevIfEditLock option is set, then a new topic is created and edited within the hour, then the date which gets stored in the rcs file is the epoch secs number rather than the date.

This then breaks the diff function and all the other revision stuff

I have uploaded an example file, and I will have another poke in the code, but if someone who knows the code better could have a look this would be great.

-- EdWildgoose - 04 Aug 2003

I can't quite see what is breaking here, but I think my example rcs file may not be completely representative. What may be happening is that either something is going wrong with the delete revision code, or there is some wierd interaction with the delete revision code and the addRevision stuff.

I have uploaded another small rcs file example and this one was created by typing "abc", then hit edit again "def", then hit edit again "ghi", then I changed the $doKeepRevIfEditLock var to "0" and did another edit.

Certainly there seems to be a problem with the revRep stuff in rcsLite when using it on the very first revision in the file.

A workaround (a bit ugly) is to disable this stuff for the very first revision, eg in store.pm find the section in saveNew around line 552 which says

            # same user?
            if( ( $TWiki::doKeepRevIfEditLock ) && ( $user eq $TWiki::userName ) && $currentRev ) {
                # replace last repository entry
                $saveCmd = "repRev";

and change the middle line to:

            if( ( $TWiki::doKeepRevIfEditLock ) && ( $user eq $TWiki::userName ) && ($currentRev>1.1) ) {

After some basic testing this appears to work ok and simply means that the initial save becomes it's own revision and replacements tick up only from 1.2 onwards. Does this look OK as a workaround for now?

Any suggestions on how to fix properly appreciated

-- EdWildgoose - 05 Aug 2003

I'll look into this.

-- JohnTalintyre - 06 Aug 2003