Cut and pasted from Suggestions for WikitDiscussion re the diffs functionMAK (2004-06-02) First of all, I have to say, thank you (!!) very much for finally adding built-in diffs to the wiki. It's often impossible to figure out what changed in a page depending on the scope of the change and (dis-)organization without diffs, and using an external tracker had its problems. I have two requests, however, to take it slightly further.First, when I use other wikis (and now with this), I usually go straight for looking at what changed since the last version, unless it's a new page or one I've never seen before. There is still a lot of clicking involved to do so with this wiki. It would be nice if there were a "(diff)" link next to each item in the Recent Changes page to click on and go directly to diffs versus the previous revision.Second, if the revisions are relatively minor compared to the amount of content on the page, the diffs themselves are sometimes not enough to provide context and understanding. The page showing the diffs should also provide the full text of the page its self after the diffs (preferably the more recent of the two revisions involved in the comparison). That way a person can go directly to the diffs, see what changed, then read the changes in context, with a single click from the Recent Changes page.As it stands now, I find myself doing this every time I visit a page: (1) click the link from Recent Changes, (2) click the Revisions link at the bottom of the page, (3) select the first link from there, look over the revisions, and then (4) go back to the page for the bigger picture (possibly opening two tabs/windows so I can see both the diffs and the page).(Probably I'm spoiled because it so happens that I too use Use Mod Wiki elsewhere with frequency.)Thanks for the comments. I agree with some of them, yet at the same time I think it's not always a matter of making the tool match expectations (and "what everyone else does"). This wiki is a body of collective knowledge, even though it gets used as discussion forum quite a bit. Do we really want a replica of usenet? I'm not sure. Second point is that my main reason to add diffs was to prevent abuse, and make it clear that everything is recorded forever. Having said that... patches are always welcome -jcwLES I wish to add that I do feel that people tend to "chat" too much on the wiki. I tend to see it more as a book or manual that is edited constantly. I think its content should try to read like some sort of finished copy, not a discussion forum. Of course, a little communication can and should happen, exactly like these two paragraphs. But I also think that kind of discussion should be deleted and replaced with "finished copy" as soon as some sort of conclusion is achieved.I also think that newcomers should be encouraged to run a little search before deciding to create a new page. Maybe we could create guidelines to determine [what topics deserve their own new page]?RA2 (22 February 2005)I have seen an excellent algorithm for a diffs. It is operational on the website where I post my life stories.It simply shows what has been added from a version to another and it does not look too hard to implement.---> http://greenlightwiki.com/travelstories/Homepage (notice the yellow stripes on the left)Perhaps doing it for this wiki could help. It's pretty hard to see what has been changed from one version to the next without any change indicators. And I understand we can only see changes the next day which makes it pretty hard...Anyway have a look at the link above. If there is an interest, I can ask the webmaster, Ben Kovitz, for the algorithm...
LV: As far as I am aware there is currently no way to see "what" changed via the Changes page - only that "something" somewhere on the page has changed.LV: These comments are not intended as criticisms of our fine author/sponser, but just a caveat as new users begin to experiment.AK: With respect to seeing what changed it might help to take a look at tkdiff. Maybe the code there can help us to highlight the changed regions of text. The fact that the underlying representation has only a very simple markup should help, it is not as much interference as HTML would be.AK: IMHO some sort of undo/history log is required for a full production site. Without it malicious or unintentional changes may leave the site in upheaval.June 2002: this is now available via http://mini.net/tclhist/29nov2002: I would like to suggest storing wiki history inside wikit, making WikiDiff simple from within wikit -- PS.15jan2003 Dossy: It's not stored inside Wikit, but I've created an easy to use interface for accessing a page's history as part of Wikit. To see it in action: http://panoptic.com/wiki/aolserver/0^ -- I'm using ^ and - as command characters. Does anyone see any problem with this approach?16jan2003: While I don't see a problem with this, your current setup doesn't highlight what has changed. Have you seen the TIP history format? Also, I believe the author of tkoutline had suggested that the wikit page's last modified date be hyperlinked to a page similar to what your ^ page shows; do you do that as well?16jan2003 Dossy: Yes, I do want to implement a visual diff of some sort -- exposing the history the way I have was hacked together inside of 20 minutes. I plan to add visual diff in the near future, but before implementing it, I wanted some feedback from Wikit developers to see if they saw something inherently wrong or broken with my approach -- if so, I'd stop and not waste time going down ratholes. Regarding the last modified date -- I simply added another link to the menu at the bottom of the page labeled History of (page name). I could make the "Last Updated" piece be the link, but I hate non-obvious links.16jan2003 Dossy: Quick update -- I've implemented a very rudimentary visual diff modeled after the TIP diff. Go to http://panoptic.com/wiki/aolserver/0^ and click "Compare" ...16jan03 jcw - Cool. Now, all we need to do is decide on the storage side of things. This wiki copies full pages to file on each change, which get added to CVS one by one, once a day. All history is archived via . For other wiki's, I'd rather want to end up with all history stored in one file, though not necessarily the wikit.tkd file itself. Several options come to mind:
- Via VFS: we could mount a separate file as VFS (i.e. a starkit), and set things up to store copies there (trivial, simply a different path). This gives per-page compression for free, btw. Add some logic to keep only the last N changes and/or changes not older than a certain number of days, and you'd have a quick history mechanism. All based on what looks like a file system from inside Tcl, but wrapped.
- Via CVS: streamline and replicate the Tclers' Wiki setup. It'll be somewhat harder to set up (getting CVS right, and a cron job).
- New diff code: implement some sort of diff, and combine the above two approaches. Needs serious work for the diff (speed matters), but the end would be the most advanced outcome - a self-contained scalable solution, which had no external dependencies.