Item8848: topic version mismatch between txt and txt,v prevents editing
Priority: Urgent
Current State: Closed
Released In: 1.1.0
Target Release: minor
Applies To: Engine
Component:
Branches:
trunk has a side effect of being more correct in its dealing with outdated topic.txt files, which causes the view UI to disable editing.
the
Item2172 txt file was modified externally (by the commit logger), which at least for a while also committed the topic to rcs. What it
didn't do, was update the META:TOPICINFO to reflect the revision number in rcs.
so trunk correctly shows that it is viewing a non-head version of the topic by default (whereas 1.0 just blindly assumed the .txt file was the latest version) - showing the topic
REVINFO in the history bit at the bottom, and
disabling the edit and attach actions
We're going to have to provide a way for the web user to fix this - and this tool can't presume that the latest contents of the txt file are commited - it needs to do a diff, and maybe a merge.
http://trunk.foswiki.org/Tasks/Item2172 is an example (assuming no-one edits it via
http://foswiki.org/Tasks/Item2172)
--
SvenDowideit - 06 Apr 2010
Yeah, anyone who uses the trunk on foswiki.org to manage Tasks will have stumbled over this. I meant to fix it ages ago, but never got there - thanks for the report.
I'm loath to reduce the correctness of the core code, because the checks it provides are important. However we can't have uneditable content. My reactions, in order, were:
- Remove the duplication of the topic version number from TOPICINFO, but that's dangerous because it would require reference to RCS to find the version number (slow),
- Automatically refresh the cache from the ,v, but that's too dangerous because an external process may not have updated RCS, causing data loss,
- Provide an external tool to synch the topic versions if they mismatch, as you suggest,
- Throw my hands up in despair, because none of those solutions appeals, and recode the view process to tolerate this mismatch (and the confusion it brings)
--
CrawfordCurrie - 06 Apr 2010
I'm leaning towards the idea of an option
5 : have foswiki treat the view request to such a topic as a merge senario - as trunk already has the info to know that the numbers are out of sync.
--
SvenDowideit - 06 Apr 2010
as trunk already has the info to know that the numbers are out of sync - how? When a topic is viewed, only the
.txt
is read, not the
.txt,v
so it has no way of knowing. AFAICT the only time you can determine it's out of date is when you read the ,v - and even then, only if it's an
rlog
read as a
co
doesn't report the rev number in a useful way.
The more I think about it, the more I'm forced to come to the conclusion that the version in TOPICINFO (and, for that matter, the date) cannot be trusted in any respect. So the logical conclusion is to clear those fields when populating a Meta from topic text. There's a cost - when viewing a topic, a read of the ,v will be required - but since that's required to check if the viewed rev is the latest anyway (to set the edit buttons) then the additional cost should be absorbed.
I think I fixed it; still needs user testing, though, especially with non-core plugins, as it's quite possible I missed something
--
CrawfordCurrie - 18 Apr 2010