Item11209: Store is returning wrong information in history
Priority: Urgent
Current State: Closed
Released In: 1.1.4
Target Release: n/a
Applies To: Engine
Component: FoswikiStore
Branches: Release01x01 trunk
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