Item11209: Store is returning wrong information in history

Store on 1.1.4 beta 1 is badly broken:

• RcsLite always shows the rev as having changed at the "current time" if the txt file is out of date from rcs. RcsWrap shows the correct modification time.
  • Enable RcsLite
  • touch a topic text file.
  • Refresh view on the topic, the modification time changes for each reload.

• Both RcsWrap and RcsLite show all revisions in history as having the same "UnknownUser" when the txt file is out of date.
  • view history on a topic with a valid rcs file.
  • touch the topic text file
  • refresh history - all revisions become the current time / unknown user

-- GeorgeClark - 27 Oct 2011

The fixes I've checked in seem to resolve the issue, and the unit tests still pass.

It does expose another issue. The post-commit hook that updates the topic checkins metadata does an rcs checkout and checkin of the topic but does not update the TOPICINFO. The result is that store trusts the TOPICINFO because the rcs "appears current" but it is actually backlevel. Since the post-commit hook is actually modifying both topic and rcs, it really ought to also update the TOPICINFO with consistent information.

-- GeorgeClark - 27 Oct 2011

"RcsLite always shows the rev as having changed at the "current time" if the txt file is out of date from rcs" is correct behaviour for both Lite and Wrap. The reason is that a file out of date w.r.t RCS will always generate a new version when an "active" operation happens - such as a save - and that new version will be timed at the time of the checkin event. You can't trust the TOPICINFO in the out-of-date file (even if it's there) because it wasn't generated by Foswiki. You can trust the creation date of the file, but that date is lost when it is checked into RCS (it is overridden by the current time).

"Both RcsWrap and RcsLite show all revisions in history as having the same...." is wrong, it should pick up the user from the RCS history.

-- CrawfordCurrie - 02 Nov 2011

sorry, your definition of 'right' is wrong.

While it might seem like a purely correct thing to do, it does not make sense to anyone other than the coder to see the last change time of a topic change every time they refresh.

the correct thing is not to scare the normal user silly by adding true correctness

same as the rentetive UnknownUser thing I wrote originally - it might be 'formally' correct and more secure, but it confused/scared users, so got removed.

I don't quite grok why we used to be able to (attempt to) commit to rcs with the file's last change timestamp and now can't, but thats an extra credit question.

       -d[date]
              uses date for the checkin date and time.  The date is specified in free format as explained in co(1).  This is useful for lying about the checkin date, and for  -k  if  no  date  is
              available.  If date is empty, the working file's time of last modification is used.

-- SvenDowideit - 02 Nov 2011

As long as the topic.txt file is older or ~ same timestamp as the topic.txt,v file, then store can trust that the topic.txt has been checked in. And it trusts the TOPICINFO, and doesn't confirm with RCS. Our old post-commit exit was proving that it worked this way because it used to do a rcs "ci" without touching the TOPICINFO .txt was therefor current, TOPICINFO trusted. But it was not updated by post-commit,. and would show the wrong information. rlog showed updates by "www" but foswiki reported update date, version and updater as whatever was left in the TOPICINFO.

I changed post-commit.pl to fix-up the TOPICINFO when it does the "ci" and everything displays consistently now.

As far as using the -d date, as long as it is consistent with the date field in TOPICINFO, I believe you can successfully update in the past. Store doesn't display the file modified time unless the file is newer than the rcs file indicating that rcs is stale. (I thought that -k meant rcs should look for $date keywords internal to the file being checked in.)

-- GeorgeClark - 02 Nov 2011

George and I discussed this on IRC yesterday and agreed that the last-modified time for the file was fine. The reason I didn't use the -d option was simply that I didn't - ensuring that the -d and the TOPICINFO were consistent was enough of a diversion from the already complex steps I had to address, so I didn't do it. Feel free to retro-fit. George, good move on the post-commit.pl.

Later: I implemented the -d on the update of inconsistent and no-history topics. George and I think this can be closed now.

-- CrawfordCurrie - 03 Nov 2011

Re-opened due to unit test failure on trunk. RCSHandlerTests::verify_OutOfDate_RevInfo_RcsLite and VCStoreTests::verify_Inconsistent_getRevisionAtTime_VCStoreTest are failing.

-- CrawfordCurrie - 01 Mar 2013

NO. This task is closed and shipped in 1.1.4, It is still closed. Once we ship a task, it has already been cast in the release notes. Please don't confuse things. This is going to cause no end of confusion, as the task will now never get closed, and will languish forever as a task waiting for 1.1.4 to be released ... again.

I don't think we want to re-release 1.1.4.

-- GeorgeClark - 01 Mar 2013

Commenting is disabled while not logged in