Bug: repRev can cause fatal time confusion in RCS

Cut and pasted this from IncorrectDateAfterRepeatedEdits

Question

After repeated edits of a topic within the editLockTime (when the revision does not get incremented), the date of the revision becomes incorrect. Instead of the current time the date gets just incremented by one minute after each save of the topic.

After looking through the TWiki sources (Store.pm), this seems to be no bug, but an "unwanted feature":

        # fix topic by replacing last revision, but do not update .changes

        # save topic with same userName and date
        # FIXME why should date be the same if same user replacing with editLockTime?
        my( $date, $user, $rev ) = getRevisionInfo( $web, $topic, "", $attachment, $topicHandler );
        $rev = "1.$rev";

        # Add one minute (make small difference, but not too big for notification)
        my $epochSec = $date + 60; 
        #TODO: this seems wrong. if editLockTime == 3600, and i edit, 30 mins later... why would the recorded date be 29 mins too early?

What would happen if I would change this to $epochSec = time() ? From the comments I suppose there might occur perhaps some race condition between topic updates and mail notification, but apart from that, would there be any other problems ?

Environment

-- JChristophFuchs - 18 Feb 2005

Answer

Heck, you may just be an accidental genius. I have been seeing a really irritating problem with ci when revisions are checked in too close to eachother. Specifically, if I make a change, save it, then go back in the browser and change again and save, then go back in the browser and change again and save, then I get an error like "time in Blah.txt,v is earlier than time". What I think is happening is that the first rev is stamped time T, then the second rev is repReved and stamped time T + dT + 60 (dT << 60). When the third rev is saved at time T + dT + dT' (<< T+dT+60) the time stamp on the file is already ahead of the 'current' time, confusing the hell out of RCS..This problem probably bites all bad typists who are also anal about spelling and grammar.

This is definitely a bug, not a feature! From a quick inspection of the code, the race condition with notification is the worst that can happen; I can't see any reason why it shouldn't work. Perhaps PeterThoeny can shed more light?

-- CrawfordCurrie - 20 Feb 2005

I've tested this further and can't get anything to break on DevelopBranch any more.

-- CrawfordCurrie - 05 Mar 2005

is this the same bug GregoryGo notes at the end of RevisionNumberNotIncrementingOnSave?

-- MattWilkie - 20 Apr 2005

Yes, I think so.

-- CrawfordCurrie - 20 Apr 2005