This topic is probably premature -- I should do some research on the output capabilities of diff, but I came across this specific example (below) of diff output that is very hard to utilize -- I cannot spot the difference without a thorough search.

Well, in fact I gave up -- I don't see any difference.

I like Word style diffs. In a Word style diff, if one word is changed, you would see the paragraph only once, you would see the deleted word with strikethroughs and the new word underlined or in bold (Word lets you set options for the display of the deleted and added word, including the use of color).

Here is an incidental example:

Aside: If the difference change is this hard to find, why do I care? If the small difference is the addition or deletion of the word "not" somewhere in a contract, it could be a very significant change. Am I going to have contracts written in TWiki? Maybe -- I am thinking about using TWiki as a collaboration tool to create specifications and contracts, with the final specification or contract "snapshotted" and stored in a less mutable form, perhaps with a GPG (?) signature.

On the other hand, persons making changes that are cosmetic only (fixing typos, addition or deletion of white space, or similar) may wish to consider checking the "Minor change, don't notify" checkbox.

Difference Topic RenameTheMainWeb (r1.8 - 10 Jun 2001 - <a href="/cgi-bin/view/Main/RichardDonkin">RichardDonkin)

Changed:
&lt; <	Just being able to change the %MAINWEB% variable is not quite enough. Apart from searching for all of the hard-coded references to Main in every web (all those Main.SomeRandomTopics!) the site-master would have to go through and change all of the ``conceptual references'' in all of the content -- all of the places where it's assumed that the ``Main'' web is the the ``Main'' that shipped with the TWiki distribution. I doubt that anyone who hasn't developed a TWikiClone has taken the trouble to modify the web structure so that ``Main'' is called something else.
> >	Just being able to change the Main variable is not quite enough. Apart from searching for all of the hard-coded references to Main in every web (all those Main.SomeRandomTopics!) the site-master would have to go through and change all of the ``conceptual references'' in all of the content -- all of the places where it's assumed that the ``Main'' web is the the ``Main'' that shipped with the TWiki distribution. I doubt that anyone who hasn't developed a TWikiClone has taken the trouble to modify the web structure so that ``Main'' is called something else.

-- RandyKramer - 11 Jun 2001

---

---

I'd certainly like to see better diff output. In GenericMetaDataStoreForTopics I suggested we move from using rcsdiff to a Perl module. On top we can put several different views of the differnces (to be honest we could do that we rcsdiff output, but if think this route would be cleaner. See for example the Web CVS for TWiki e.g. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/twiki/twiki/bin/viewfile.diff?r1=1.10&r2=1.11, with drop down at the end of the page. None of these do comparisons at the word level, but I don't see why this shouldn't be done as an option.

So, what's needed is someone with some time to code ...

-- JohnTalintyre - 11 Jun 2001

The reason there is no apparent difference in the above diff is that I made a small markup only change in RenameTheMainWeb (from one sort of <nop> to another) - see the comment about non-standard markup and Mozilla in BrowserIssues.

This does raise the need for a 'view source' that works even on previous revisions of a page - without this, it's hard to see what might have changed even if you know where it was. See ViewRawPage for a patch that would do this (though perhaps this feature should be configurable, i.e. normally omitted from standard templates).

I think I did check the 'minor change' box on Preview, but I don't think this affects the .changes file and hence the WebChanges search - doesn't it only affect WebNotify?

-- RichardDonkin - 11 Jun 2001

Thanks, that may be the case -- I'll have to test it. I do know it showed up in the recent changes, and it may be nice for an option to ignore minor changes there as well. (That might be a two part option -- the editor would have to check "Minor change, don't notify" which would designate changes as minor, but the viewer of the recent changes page could have an option to view or not view the changes that have been designated as minor.) (I know, I have a tendency to go overboard.)

-- RandyKramer - 12 Jun 2001

The interpretation of how important the change can be best left to the reader, than the person making the change. The person making the change should tick one of the boxes:

 - This is a gramatical/formatting correction
 - No change in semantics; just a minor change in the wording 
   of the sentence
 - Added/Removed/Changed information to a paragraph
 - Major change affecting multiple paragraphs

And ideally, we could have the software do this for us, rather than user do this.

Tracking changes are important. One of the problems we have had in our installation of TWiki is that people can't track the changes easily. Email is still a good model for collaboration because people get triggerred by the email-received event, and can act on it according to different priorities. To incorporate this model into wiki concept is an important challenge. Simple "notify me" won't do it; it should be more than that. The "type of change" as defined above will help in that (i.e. I will subscribe to the topic to notify me for only major changes). An yet higher level of "personalization" of tracking the changes would be to let the topic writer define the changes that are meaningful for the topic. For example, if I am maintaining a list of restaurents, the changes would be:

  - Added/removed a restaurent information
  - Added more info to specific restaurent

and so on. Eventually it should be the way humans communicate the change by email: Something like: "I just added a new section to the document we are writing. Can you review it?". That is more natural, and allows us to retain the human aspects involved in collaboration. So the big challenge is, what is the best way to capture the changes and integrate them into personalizable emails? I even thought that the easiest thing is to first make a change in twiki, and then to also add a personalized message to the group that is tracking the change, to be sent as email - all in single interface.

-- VinodKulkarni - 14 Jun 2001

How about using the RCS comment field for that purpose? Just add a small box to the edit page, where you can enter a short revision description.

-- PeterKlausner - 24 Jun 2001

I find that even with a well used source code control system, people often fail to fill in good revision contents. Given the nature of TWiki I think it even less likely that people will do this. I think even the current two checkboxes (release lock and minor change) are not understood or used by most users.

I'd rather see a new function to add a comment to a topic, rather than comments for revisions. Having said that, the next version of TWiki has attachments in RCS and the comment field is used.

-- JohnTalintyre - 25 Jun 2001

See WordDiff for discussion of word-level diffs. This would not be a hard thing to do using GNU wdiff.

-- RichardDonkin - 01 Aug 2001

There is a gpl-ed bit of code called ediff.el (documentation, code) that does a very nice colored diff based on gnu diffutils's diff. One is able to identify exactly which part of lines and even whole paragraphs have changed (type M-X ediff in emacs or xemacs, choose the files to be compared, then choose options "ignore whitespace" and "auto-refine", maybe also "hilighting" in case it is not a default in your distribution), so merely reformatting paragraphs do not lead to diffs. Unfortunately it is written in emacs-lisp and must be used interactively (jump from one change to next), but it could be a good source of inspiration. The interactive ediff-merge is also much more powerful than the one in cvs etc, as it allows to merge two different changes in one line (no conflict here) and even when paragraphs have been reformatted. Obviously, this should better be done interactively.

Here is a picture of what the output looks like (copied from ), where option "ignore whitespace" was not selected (so the string "at once" is marked as a change despite beeing only on a different line):

-- WolfgangSlany - 31 Dec 2003

Another example of a beautiful (line) diff: http://dev.rubyonrails.com/changeset/991

-- ArthurClemens - 20 Aug 2005

Has anyone successfully used something besides rdiff? I really want diffs down to the character level like most other wikis.

-- RyanKnoll - 23 Feb 2006

CompareRevisionsAddOn is a bet in this direction. Hope someone will raise it to Dakar eventually.

-- SteffenPoulsen - 23 Feb 2006

CompareRevisionsAddOn has now been updated to Dakar

-- JChristophFuchs - 27 Feb 2006

Excellent! - Thanks a bunch, will try it out asap.

-- SteffenPoulsen - 27 Feb 2006