Item9714: compare doesn't show form changes. No indication of what has changed in revision

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

Commenting is disabled while not logged in