Priority: Urgent
Current State: Closed
Released In: 1.1.0
Target Release: minor
Applies To: Engine
Component: compare
Branches:
The default compare vs. rdiff doesn't show form changes.
For example:
http://trunk.foswiki.org/bin/compare/Tasks/Item9702?rev1=4;rev2=5 doesn't show any obvious changes
http://foswiki.org/bin/rdiff/Tasks/Item9702?rev1=4&rev2=5 details the form changes.
When a user clicks the ">" to compare two revisions, they should see similar results.
--
GeorgeClark - 19 Sep 2010
Compare works fine in 1.0.10 and shows the individual words that changed in the form fields. In 1.1.0 code the plugin is blind for the form changes. I cannot remember anyone changing anything in the
CompareRevisionsAddOn so it may be the core API that suddenly does not include the meta changes. There has been earlier bugs where the refactored store did not return the original meta from earlier revisions. That would be the first place to check. I dount it is the plugin that changed.
This is a serious release blocker. The compare as well as rdiff must show changes in form fields.
--
KennethLavrsen - 21 Sep 2010
around line 316 in
_getTree()
, there's something going wrong there -
%META{"form"}%
and
%META{"attachments"}%
mustn't be working.
- I don't understand
enterContext('can_render_meta', $meta)
so that we can call expandCommonVariables
on the whole topic text. Shouldn't we just expand the string '%META{"form"}%\n%META{"attachments"}%'
separately and concatenate that onto the topic text? And instead of expandCommonVariables
, $meta->expandMacros('foo')
is good too...
--
PaulHarvey - 21 Sep 2010
There's an
enterContext()
, but no corresponding
leaveContext()
in that method
--
PaulHarvey - 21 Sep 2010
It appears that for some reason Func::expandCommonVariables returns the current topic version of %META on 1.1, but the loaded rev version on 1.0.x. "A fix" (but maybe not the right fix) was to add the meta object to the call to expandCommonVariables. But why has this changed for 1.1? And what else will be broken?
--
GeorgeClark - 22 Sep 2010
From IRC Log:
(11:14:53 PM) Babar: hum... just quickly reading getRendererVersion, and it uses meta... but it's called from renderText, which creates a new meta
(11:14:57 PM) Babar: hence, it ought to break
(11:15:03 PM) Babar: but it's too late for me, so...
(11:16:14 PM) Babar: so either getRendererVersion doesn't need its $topicObject meta, so it should be trashed, or it does use it, and then it should be passed along from renderText, and given to it when $meta isn't the latest rev
Func::expandCommonVariables has been changed to create a new Meta object unless $meta is passed to it. So it ends up reading in the current topic. 1.0 calls the Session->handleCommonTags call with the meta object - defined or not.
--
GeorgeClark - 22 Sep 2010
IMHO it was a "happy accident" that in the past, the right version happened to be in place. If you need to control the version, then you should control the version, as you have done by passing the meta object. Assuming context is never a good idea.
--
CrawfordCurrie - 22 Sep 2010
This seems fixed now. Any reason it is still open?
I am setting it to Closed.
--
KennethLavrsen - 26 Sep 2010