--
JChristophFuchs - 20 Jan 2005
Thanks Christoph for sharing this add-on. Very intuitive output!
--
PeterThoeny - 21 Jan 2005
Hi Christoph, cool add-on!
Unfortunately the algorithm is very sensitive when it comes to the ugly <p />-tags, spreaded all over twikis HTML rendering
For example, when you have a headline followed by a bullet list, and then you insert a blank line between them, compare will replace the whole list. Do you see a work around for this, or is it time to get rid of the <p />-tags altogether?
--
AndreUlrich - 01 Feb 2005
Yes, I also noticed this. I just uploaded version 1.1, which removes the blank paragraphs before comparing the revisions.
--
JChristophFuchs - 03 Feb 2005
Hi Christoph, your add-on is very helpful in understanding more complex changes!
I have just installed it in our TWiki instance. However, our apache server complains constantly about uninitialized variables, which are all located in the subroutine _compareText:
[error] ... d:\\twiki\\bin\\compare: Use of uninitialized value in string ne at ../lib/TWiki/UI/Compare.pm line 397.
[error] ... d:\\twiki\\bin\\compare: Use of uninitialized value in string eq at ../lib/TWiki/UI/Compare.pm line 416.
[error] ... d:\\twiki\\bin\\compare: Use of uninitialized value in string eq at ../lib/TWiki/UI/Compare.pm line 416.
[error] ... d:\\twiki\\bin\\compare: Use of uninitialized value in string eq at ../lib/TWiki/UI/Compare.pm line 416.
[error] ... d:\\twiki\\bin\\compare: Use of uninitialized value in concatenation (.) or string at ../lib/TWiki/UI/Compare.pm line 434.
[error] ... d:\\twiki\\bin\\compare: Use of uninitialized value in concatenation (.) or string at ../lib/TWiki/UI/Compare.pm line 435.
To me it seems to be a boundary problem with some index?
--
MichaelSchmidt - 28 Feb 2005
Hi Michael, thanks for your help.
The bug has been corrected, I have uploaded a new version of the addon.
--
JChristophFuchs - 02 Mar 2005
Has anyone managed to get
CompareRevisionsAddOn to work with
TWikiRelease01Feb2003?
I've done the following:
- updated Algorithm::Diff to the version (1.13) that includes sdiff
- replaced all references to formatTime (not supported in Beijing?) with formatGmTime
- replaced all references to TWiki::Render::getRenderedVersion (undocumented function?) with TWiki::Func::renderText
The compare script now runs, but I get only
partially rendered pages back and the somewhat cryptic
grep: *.txt: No such file or directory
(twice) in the http error log. I kind of feel bad about posting this without debugging it properly, but just wondered if anyone had any ideas about what might be going wrong.
Thanks!
--
MartinRothbaum - 21 Mar 2005
Hi Martin,
Sorry, I do not have any old TWiki version installed, so I cannot debug
CompareRevisionsAddOn on
TWikiRelease01Feb2003. However, the following points might help to fix the problem:
When I started to write the addon, I tried to use only documented routines from the Func module.
However, I did not succeed in getting a fully html rendered topic including the meta data. So I
decided to use other routines from TWiki (the only documented routine from the Func module which
deals with meta data seems to be the deprecated readTopic).
The rendering text -> html is done in subroutine _getTree with the call to TWiki::handleMetaTags,
which internally in
TWikiRelease01Sep2004 calls Twiki::Render::getRenderedVersion. It is very likely that this has changed since older versions.
You could try to replace the section labeled '# Process Meta data' in Compare.pm (lines 258-267)
by
$text = TWiki::Func::expandCommonVariables($text, $topic, $webName);
$text = TWiki::Func::renderText($text, $webName);
but this will print meta data in their internal form '%Meta...', which is not very user friendly.
The call to TWiki::Render::getRenderedVersion in Compare.pm is only in the routine getRevInfo, which
was copied from TWiki::UI::RDiff. The addon should work even without this subroutine.
There are no calls to grep in the addon, so the error message in the log file must be from some TWiki core module ?
--
JChristophFuchs - 24 Mar 2005
I'm trying to make a "WikiPedia killer" TWiki system with this plugin along with
HistoryPlugin. Can interested parties please see more details at
MediaWikiHistoryAndComparisonInTWiki and comment there?
--
MattEngland - 09 Apr 2005
I think, there is a bug in handling html-comments. On my system, users sometimes use html-comment-tags to hide unfinished or noisy parts of a topic. Viewing the topic with the
CompareRevisionsAddOn the content of the html-comment comes to surface.
--
OliverKrueger - 05 May 2005
Hi Oliver, I was not able to reproduce this bug. Could you please send me a test case
(topic text and rcs repository) for debugging ?
--
JChristophFuchs - 09 May 2005
Christoph tracked down this problem to a nested html-comment, which is not allowed by definition (
W3C). -- Thanks.
--
OliverKrueger - 09 May 2005
(Nested html comments are rendered differently by different browsers: Mozilla, Firefox etc
do not show netsed comments, which is not correct, but in most cases intended by the author.
Internet Explorer, Opera and Lynx render them correctly: they show the second part of the
outer comment.
CompareRevisionsAddOn also handles nested comments in the correct way
(with the help of perl modules from HTML::TreeBuilder),
even if this surprises the author.)
--
JChristophFuchs - 10 May 2005
Has anyone managed to get this to work with
DragonSkin? Any help would be appreciated.
--
PankajPant - 09 May 2005
I have attached templates
compare.dragon.tmpl
and
interweave.dragon.tmpl
in
dragonskin.zip
--
JChristophFuchs - 10 May 2005
Thanks. I'll check it out.
--
PankajPant - 10 May 2005
Hi, does anyone have an idea what could go wrong when, after installing this Add-On, I get:
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please comment in
CompareRevisionsAddOnGivesInternalServerErrorFivehundred if you have an idea. Thanks!
--
JosMaccabiani - 10 Jun 2005
Due to a wierd problem with dates on TWiki.org I can't edit the abovementioned topic, but I wanted to state that
JChristophFuchs solved my problem. Thanks!
--
JosMaccabiani - 10 Jun 2005
By the way, consider mentioning the possible combination of
HistoryPlugin,
CompareRevisionsAddOn and
RevCommentPlugin. They work together really nicely and the last one even provides the oopshistory.tmpl to integrate the three plugins, making the whole thing rather painless.
--
JosMaccabiani - 10 Jun 2005
added
.zip
to
CVS
--
WillNorris - 27 Jun 2005
Dont see the point of having strike-out AND red background - the latter should be sufficient and the strike-out just makes things harder to read.
--
JackGlendeni - 09 Nov 2005
This is not hard-coded: Just change the default styles in the supplied template files to your needs
--
JChristophFuchs - 11 Nov 2005
I installed the
CompareRevisionsAddOn. I am able to make it work but was expecting that it would seamlessly replace the existing rdiff. Is there a simple (considering my lack of knowledge of perl etc) way to make it replace rdiff ? My wish is that when I click on the '>' sign displayed at the bottom between the revisions, I should get the output from this add-on, with sidebyside rendition and pattern skin (though I am using dragon skin for the pages)
--
ChengappaCB - 24 Nov 2005
Please see my answer in
CompareRevisionsAddOn
--
JChristophFuchs - 24 Nov 2005
When I use the add-on in the way described in
CombineHistoryPluginWithCompareRevisionsAddOn, I observe that the compare function only works for webs that are not protected by access control like ALLOWWEBVIEW. For any topic of a protected web I get the error message "View Access Denied". I am eager to know, what has to be changed in order to being able to compare revisions in protected webs too.
--
MichaelSchmidt - 14 Dec 2005
I am not familiar with this add-on. It looks like
bin/compare
needs to be authenticated (which requires users to login to see the diffs). Alternatively,
bin/compare
could be enhanced to redirect to an authenticated
bin/compareauth
if needed (in the same way the
bin/view
script works.)
--
PeterThoeny - 15 Dec 2005
Thanks for the hint. The problem arose after setting the configuration variable $doRememberRemoteUser to 0 which was necessary due to the fact that some users are accessing twiki with the IP address of some proxy. BTW rdiff caused the same error.
Meanwhile I found, that the problem is resolved by choosing the option to force authentication for all files in the .htaccess file of the \bin directory.
--
MichaelSchmidt - 16 Dec 2005
This is an add-on I would really like to see available for Dakar.
The way it shows changes in large documents with a lot of text is far superior to the normal rdiff in TWiki. For seeing changes of TWiki valiable and other hidden stuff the rdiff is better so we use both at the moment.
I just tried to install it in Dakar and it seems the structure in the core code has changed quite a bit so this add-on is no longer compatible at all.
I get this error when I install and run it (and have updated the shebang line of bin/compare).
Can't locate object method "read" via package "TWiki::Meta" at /usr/local/apache2/dakar/lib/TWiki/UI/Compare.pm line 259.
I tried to see if it was something simple but the different in the TWiki::Meta is beyond my rudimentary Perl skills.
--
KennethLavrsen - 20 Dec 2005
Can someone help me with some hint of how to make this add-on work?
And for those that do not know it - it is fantastic - when it works.
--
KennethLavrsen - 05 Feb 2006
Many thanks for updating the addon for Dakar! My initial tests were successful.
--
ScottHoge - 27 Feb 2006
Tests also very successful here. My users are very happy to have the this wonderful feature back.
Note that you may need to make tamplate updates when 4.0.2 is out since the pattern skin is about to change back to a pure DIV defined skin (no tables). It should however - from what I have seen - also be much simpler to taylor.
But great work. And to those that only live with rdiff. You should really consider this plugin. Highly recommended.
--
KennethLavrsen - 27 Feb 2006
Christoph, thanks for updating the add-on. Please consider upgrading this add-on so that it runs on Cairo
and Dakar codebase.
HandlingCairoDakarPluginDifferences has more.
If you prefer to maintain just the Dakar version, please remove the
CompareRevisionsAddOn.Dakar.zip
file and overwrite
CompareRevisionsAddOn.zip
with the Dakar version. In the add-on doc you can point to a previously attached zip version for the Cairo version.
--
PeterThoeny - 27 Feb 2006
I will maintain both the Cairo and Dakar versions, and combine the two versions eventually.
--
JChristophFuchs - 01 Mar 2006
Could someone please check this issue
PrintableStoppedWorkingShowsTheSameAsNormalView which I had with
CompareRevisionsAddOn.
I solved my problem here
PrintableStoppedWorkingShowsTheSameAsNormalView but it appears to me as a problem related to the plugin and not to my particular configuration.
--
DaliborSvoboda - 07 Mar 2006
Thanks for the hint. I indeed did not check all implications of the VIEW_TEMPLATE preference variable. I have changed the install instructions for the plugin so that you should replace the view templates by the provided templates and not use this prefernce variable.
--
JChristophFuchs - 07 Mar 2006
The pattern skin had a major update between TWiki 4.0.1 and TWiki 4.0.2. Between Cairo and TWiki 4.0.0 the Pattern Skin had been changed into a table layout. This caused serious trouble when you had graphics and verbatim text. So serious that many topics could not be viewed or printed at all. So in TWiki 4.0.2 the Pattern skin was changed back to a pure style sheet defined design and all is working fine again. Except 2-3 extensions that depend on the Pattern skin. And
CompareRevisionsAddOn is one of them. Could I kindly ask you to update the templates so they work with 4.0.2 again?
My users love this extension so much but since I upgraded to 4.0.2 I just get a blank screen when using it.
--
KennethLavrsen - 08 Apr 2006
Any reason this can't get bundled with the core? Its baseline functionality wrt: other wikis.
--
MartinCleaver - 08 Apr 2006
And while we're at bundling baseline functionality in the core: please also consider
HistoryPlugin and
RevisionCommentAddOn for this! (e.g. turned 'off' by default)
--
JosMaccabiani - 08 Apr 2006
Martin. In my view - the way this add-on works should be a replacement for the current rdiff. It is far superior. But I have seen some small glitches in a few cases where this add-on is not perfect so it would need a little more testing.
SteffenPoulsen has made a fix for the compare.pattern.tmpl and interweave.pattern.tmpl which works fine. I will check them into SVN. There is still some work missing to get the view_cra.pattern.tmpl made.
--
KennethLavrsen - 09 Apr 2006
Hi Christoph, this is a very cool plugin! I updated this and
HistoryPlugin to be 4.0.2 compatible in SVN (TWiki4 branch), feel free to use this as input for next release :-).
I did some changes:
- Changes view changed from full view with top/left bar, to a more simple view
- Took out
view_cra.pattern.tmpl
and put in viewtopicactionbuttons_cra.pattern.tmpl
(thinking of it, this is not optimal for 4.0.0 and 4.0.1 ... hmmm, I guess people should consider upgrading to 4.0.2 asap anyway :-)).
- Template support for both rdiff and compare in HistoryPlugin, dependent on context
CompareRevisionsAddonPluginEnabled
Thanks again, hope this plugin will come closer to the core eventually (in spite of the additional
CPAN requirements)!.
--
SteffenPoulsen - 09 Apr 2006
I was wondering, how much effort would be needed to make this excellent plugin show diffs in META as well?
--
SteffenPoulsen - 12 Apr 2006
Since the plugin compares the html-rendered output of a topic, differences in METAs are normally not shown.
However, if you can include your META data in the rendered output, differences will be shown. This is presently done for the list of attachments and for form fields, which are both stored as META data.
--
JChristophFuchs - 12 Apr 2006
Ah, I see, that's the way to go. I was thinking along the lines of "all meta", like current diff functionality that will also display arbitrary meta changes, like
> META REVCOMMENT comment_1="New responsibilities for software maintenance" minor_1="" ncomments="1" rev_1="" t_1="0"
< META REVCOMMENT comment_1="Updated with new server info for front setup" minor_1="" ncomments="1" rev_1="" t_1="0"
But I guess that would require some kind of way to render
all meta as HTML. Or perhaps just separate the remaining bits out, along the lines of a
%META{"other"}%
.
Forms and attachments are the most important, need to consider the last part a bit more.
(BTW:
merlin.lavrsen.dk is running an SVN install where you can see the 4.0.2 look in action).
--
SteffenPoulsen - 12 Apr 2006
I am sorry to announce that I am no longer able to do any work on this addon. For more information please read
JChristophFuchsStopsWorkOnTWikiPlugins.
--
JChristophFuchs - 13 Apr 2006
Thanks for your effort, JC!
Uploaded a new version from SVN, compatible with
TWikiRelease04x00x02. Users on earlier releases of TWiki should use:
Latest
PatternSkin (in SVN) supports this plugin directly, but is not released yet. Until next release of PatternSkin the updated template
viewtopicactionbuttons.pattern.tmpl
supporting this plugin can be retrieved from this link:
viewtopicactionbuttons.pattern.tmpl in SVN.
--
SteffenPoulsen - 13 Apr 2006
I added a SHORTDESCRIPTION to the "Add-On Info" section so that this add-on is represented properly in the
AddOnPackage topic and query topics. Please feel free to take this into the next release.
--
PeterThoeny - 06 Oct 2006
It seems to have a problem with UTF-8 encoding. I guess it's related with HTML::Parser, but couldn't manage it to work.
--
KyungdahmYun - 29 Mar 2007
now there's an addon who's functionality should have been merged into the core years ago. I don't know why no-one's done so - but anyone that is interested, please think about doing so.
especially as when i wrote rdiff (the Cairo version was a complete re-write), i made it kind of pluggable!
--
SvenDowideit - 20 Jul 2007
--
SvenDowideit - 20 Jul 2007
I agree ... into the CORE !
--
KeithHelfrich - 20 Jul 2007
It is the very good proposal, and by the way
Bugs:Item3683 can be eliminated.
(This wonderful script suddenly stopped to recognize custom charset without any visible reason)
--
SergejZnamenskij - 21 Jul 2007
Does anyone know whether this Add On works with TWiki 4.1.2? I'm really keen to use it.
--
TamsinTweddell - 30 Aug 2007
Works great on 4.1.2, I'm using it on a daily basis! Thanks Steffen!
--
FranzJosefGigler - 30 Aug 2007
There is a new version ready for 4.2. Unfortunately incompatible changes in the 4.2 template system makes the new version of
CompareRevisionsAddOn totally incompatible with 4.1.2 and earlier.
So once we release the 4.2.0 version - a 4.1.X user that accidentally update this extension with Configure will see themselves in a lot of trouble.
I have raised
Bugs:Item5117 to address this issue. I am not sure it will be an easy one to resolve.
It is a real pity that we allowed these incompatible template changes in 4.2.0 IMHO.
The worst part is that the developers learn nothing of the past. Just see
JChristophFuchsStopsWorkOnTWikiPlugins. This is exactly the same that happens again now.
--
KennethLavrsen - 12 Dec 2007
I am sorry to say, but with 4.2 we are
correcting templates incompatibilties I have created earlier. So it is no longer needed to have a special
pattern
template for each plugin.
The reason why we changed (again) is exactly to address this issue.
But I don't find it very encouraging to find rants from one Core developer against the other on random places on twiki.org.
--
ArthurClemens - 12 Dec 2007
Template work is complicated and takes quite a lot of energy - as I guess you have recently experienced, Kenneth.
I also guess that when you revisit your comment now you will acknowledge that you are way out of line here, but I can understand the frustration - I've been there myself
If we look back at
the roadmap agreed at our latest summit we discussed the interest in a stable template baseline, and Arthur is already doing incredible work in this direction - even though
none of us voted this item as one of our top priorities. What would you vote if you had to vote right now?
Anyway, it is perfectly ok to let off steam - but remember, it is also perfectly ok to find a way to come clean again afterwards ..
--
SteffenPoulsen - 12 Dec 2007
I am not personally affected by this issue. I do not upgrade the plugin in 4.1.2. I upgrade to TWiki to 4.2.0. I am talking on behalf of the customers who will not all go and upgrade to 4.2.0 tomorrow.
I wrote the statement above - here - to warn people that may consider upgrading - and developers who may consider uploading the 4.2.0. And the rant - well - it is my hope that this time developers will learn and remember that changes to templates and plugins must consider compatibility. The roadmap suggestion was mine. I raised it
after these template changes were made because I feared issues like this would be the effect.
What are we going to do about the problem with this plugin?
--
KennethLavrsen - 13 Dec 2007
As a general solution (for all plugins) we could offer a general pattern skin template update for TWiki 4.0.5 up to 4.1.2.
--
ArthurClemens - 13 Dec 2007
If that is possible then it sounds like the best possible solution.
But it sounds like a big job. But I will be happy to help testing it.
--
KennethLavrsen - 13 Dec 2007
The short description settings that has been added is lost. Please add something like this to the add-on topic:
- Set SHORTDESCRIPTION = Compare two topic revisions and shows the differences on a word-by-word level
--
PeterThoeny - 04 Feb 2008
This plugin doesn't actually display all changes as advertised. An image on the plugin topic shows tables as a single table with changes rendered inside table cells. On our 4.2 installation, any changes in tables are rendered with the whole table removed and re-added. There are some other issues also (the default style preference doesn't work). Having scanned over the above discussion - is this plugin still being maintained/developed?
--
MarcusLeonard - 02 Apr 2008
ArthurClemens and I
KennethLavrsen are trying hard to keep it up to date.
I have also noticed the table problem which partly seems to be when an old topic is edited by Wysiwyg which cleans out extra whitespace - or when you insert new rows.
Do you have some patches to the default style preference. Any improvements you have I will be glad to test, check into Subversion and upload as a new version here on Plugins web at twiki.org
--
KennethLavrsen - 02 Apr 2008
Um. My Perl sucks. I'll have a look at the preferences thing, but
. As for the table-as-single-unit issue (which is more important to us), I've just done a quick test. I didn't use wysiwyg at all. I changed the contents of one cell and the whole table was treated as changed.
But really, this is part of a wider problem I've been chewing over. It's probably fodder for a Codev topic, but I'm not a developer so I'm not sure of the protocol here. In a very small nutshell, without any supporting arguments (which I'm happy to provide) my thoughts are...
The introduction of wysiwyg as default editor is a very important shift in the interaction metaphor away from TWikiML, and makes a strong argument for the inclusion of a more "user-friendly" "track-changes" style of version diff display, because TWiki users will now be increasingly
removed from TWikiML, so diffs should be based more on "end result" information in line with what they're seeing in normal View and now in Edit. The same metaphor should operate across the system.
We're now apparently in a situation where core developers (you
) are maintaining abandoned plugins like this
anyway because there's a demand, so there's a strong argument to either bring it into the core or update the core system to cover the basic functionality of the plugin. (A certain level of the popularity of a plugin should be a pathway to have it brought into the core.)
So the display of changes to topics should be revamped to at least include the basic functionality of this plugin. I doubt that end-users will complain and there's already some voting above. I like the new "debug" diffs, it's great for my TWiki apps, but it's in the other direction for end-users.
Not sure how much weight my argument/opinion carries 'cos I'm not going to pony-up the code. But anyway.
--
MarcusLeonard - 03 Apr 2008
After installing this Add on, I noticed that any searches that included the Sandbox web (such as
Sandbox.WebHome
) were broken and displayed an error long lines of
Could not perform search. Error was: /bin/grep -E -i -l -H -- %TOKEN|U% %FILES|F% Grep for '.*' returned error
. After some mucking around, I finally figured the problem was that the distributed version of
Sandbox/CompareRevisionsAddOnDemoTopic.txt
had permission set to 000. For some reason, this causes grep to choke. Correcting the permission on the file level fixed everything. Just thought I'd mention this in case someone else runs into problem and note for someone to fix in future releases.
--
LynnwoodBrown - 17 Sep 2008
I have checked both the tgz, the MANIFEST and the
Sandbox/CompareRevisionsAddOnDemoTopic.txt
has the correct 644 setting so it is something that went wrong in your installation Lynnwood.
--
KennethLavrsen - 18 Sep 2008
Had that happen to me too. And I'm still not able to use this addon reliably on my
TWikiVMDebianStable. Whenever I activate the corresponding Plugin the
compare
results in an empty page. Strange. Always thought it must be something wrong with my installation, but I did'nt find out what yet, so I chose to wait for somebody else to report something similar.
--
FranzJosefGigler - 18 Sep 2008
Bugs:Item6126 on broken UTF-8 characters filed.
--
KyungdahmYun - 18 Nov 2008
I need to set the param rev to the correct value in compare.pm sub _getTree to get the right value for %REVINFO%:
...
my ( $meta, $text ) = TWiki::Func::readTopic( $webName, $topicName, $rev );
$text .= "\n" . '%META{"form"}%';
$text .= "\n" . '%META{"attachments"}%';
# patch to get the right value for %REVINFO%
$session->{cgiQuery}->param( 'rev', $rev );
$session->enterContext( 'can_render_meta', $meta );
...
--
ManfredMeiser - 2009-08-28