Item8848: topic version mismatch between txt and txt,v prevents editing

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:

1. 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),
2. Automatically refresh the cache from the ,v, but that's too dangerous because an external process may not have updated RCS, causing data loss,
3. Provide an external tool to synch the topic versions if they mismatch, as you suggest,
4. 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

Commenting is disabled while not logged in