Submitted by : simon at: 2003-10-26T21:31:28+00:00 (14 years ago)
Name :
Category : Severity : Status :
Optional subject :  
Optional comment :

Problems with Zwiki's old zodb-transaction-based diff browser:

Related:

Also

design

Questions/needs that users might have:

  • what versions of this page have there been ?
  • show me a version from last week ?
  • revert to the last spam-free version
  • what changed between these two versions ?
  • step through the changes
  • how has this page's name changed ?
  • what other changes should I know about ?

Most wikis have a history view showing an overview of changes and a detail view zooming in on one particular change, usually showing some kind of textual diff. We will need both.

property change --SimonMichael, Mon, 09 Aug 2004 15:41:03 -0700 reply

Name: 'IssueNo0047? issues with diff browsing' => 'IssueNo0047? need more attractive history/diff browsing'

examples --SimonMichael, Mon, 09 Aug 2004 15:48:15 -0700 reply

current zwiki - diff: http://zwiki.org/FrontPage/diff

viewcvs - diff: http://dev.eclipse.org/viewcvs/index.cgi/platform-webdav-home/dev.html.diff?r2=text&tr1=1.1&tr2=1.6&r1=text&diff_format=h

wikipedia - history: http://en.wikipedia.org/w/index.php?title=Main_Page&action=history , diff: http://en.wikipedia.org/w/wiki.phtml?title=Main_Page&diff=0&oldid=5028604

swiki - history: http://wiki.squeak.org/squeak/3501.history

moinmoin - history: http://moinmoin.wikiwikiweb.de/WhyWikiWorks?action=info

in progress! --simon, Mon, 16 Apr 2007 23:58:43 +0000 reply

Name: '#47 need more attractive history/diff browsing' => '#47 need permanent revisions and better history/diff browsing' Severity: wishlist => funded

testing --simon, Fri, 27 Apr 2007 02:10:31 +0000 reply

Name: '#47 need permanent revisions and better history/diff browsing' => '#47 permanent revisions and better history/diff browsing'

This is now running on zwiki.org and needs testing to see what else is needed. Here are some notes:

  • there is a new /history view. Clicking the last edit time goes there now, also the y access key goes there instead of to ZMI history tab
  • page revisions are permanent. They are stored in the revisions subfolder in the zodb, as copies of the page object with .N appended to the id.
  • the recycle_bin subfolder is no longer used and can be deleted
  • in the history view, click a revision to see the detail for that edit (or use the d access key to see the last edit, as before)
  • the edit detail (diff) view is a little different; it now shows the colour-coded text diff, then a horizontal rule and then the full rendered body of the current revision. Hopefully this will work out ok. You can navigate forward or backward or click on a specific revision number. Layout will need a bit more work for many revisions.
  • revert currently saves a new revision with new editor and edit time, see #1157

Comments welcome!

Comments welcome! --EmmaLaurijssens, Fri, 27 Apr 2007 17:09:57 +0000 reply

You're sure?

  • Only the last /diff revision shows rendered wikilinks correctly, earlier revisions show wikilinks as if the pages don't exist, i.e. with a question mark. Either wikilinks should always render, or they shouldn't render at all.
  • IMHO we need a way (link, button) to go back to the normal page view.

Comments welcome! --Simon Michael, Fri, 27 Apr 2007 18:25:07 +0000 reply

> * Only the last /diff revision shows rendered wikilinks correctly, earlier revisions show wikilinks as if the pages don't exist, i.e. with a question mark.

True, all but the current revision are rendered as in a different wiki (the revisions folder). Should be fixable.

> * IMHO we need a way (link, button) to go back to the normal page view.

Return to edit history -> Return to page ? (and v access key for power users)

test failure in CMF tests --betabug, Fri, 04 May 2007 07:05:13 -0700 reply

This is what I get:

Error in test testPageSaving (Products.ZWiki.CMF_tests.Tests)
Traceback (most recent call last):
  File "/usr/local/lib/zope296/lib/python/Testing/ZopeTestCase/profiler.py", line 98, in __call__
    testMethod()
  File "/Users/betabug/zope/lizard/Products/ZWiki/CMF_tests.py", line 108, in testPageSaving
    self.portal.TestPage.append(text='test')
  File "/Users/betabug/zope/lizard/Products/ZWiki/Editing.py", line 246, in append
    self.edit(text=self.read()+separator+str(text), REQUEST=REQUEST,log=log)
  File "/Users/betabug/zope/lizard/Products/ZWiki/Editing.py", line 312, in edit
    p.saveRevision()    File "/Users/betabug/zope/lizard/Products/ZWiki/History.py", line 72, in saveRevision
    self.ensureRevisionsFolder()    File "/Users/betabug/zope/lizard/Products/ZWiki/History.py", line 55, in ensureRevisionsFolder
    self.folder().manage_addFolder('revisions', 'wiki page revisions')    File "/Users/betabug/zope/lizard/Products/CMFCore/PortalFolder.py", line 569, in manage_addFolder
    self.invokeFactory( type_name='Folder', id=id )    File "/Users/betabug/zope/lizard/Products/CMFCore/PortalFolder.py", line 408, in invokeFactory
    return pt.constructContent(type_name, self, id, RESPONSE, *args, **kw)     File "/Users/betabug/zope/lizard/Products/CMFCore/TypesTool.py", line 934, in constructContent
    ob = info.constructInstance(container, id, *args, **kw)    File "/Users/betabug/zope/lizard/Products/CMFCore/TypesTool.py", line 341, in constructInstance
    raise AccessControl_Unauthorized('Cannot create %s' % self.getId())
Unauthorized: Cannot create Folder

Looks like ensureRevisionsFolder and cmf don't like each other too much yet.

improvements --simon, Mon, 07 May 2007 17:42:20 -0700 reply

* more robust history
- allow partial history, revisions can safely be deleted
- use a btree folder for revisions if possible
- more zodb cache friendly
- richer history api

Pages now keep their revision number as a read-only attribute, as well as in the id in the revision folder (so a page will remember its revision number). It was simplest to forget about the old revisions created in the last week or two, and I've done this on zwiki.org. Let me know if you need access to that history for some reason.

fragility --simon, Sun, 03 Jun 2007 10:04:57 -0700 reply

There is fragility here, which I have encountered a number of times, related to tracking the revision number in two places (as a page attribute and in the revision ids). You save a page A whose revision is N, but somehow the A.N revision already exists in the revisions folder, so it fails. I think this can arise through conflicts, zeo-related glitches, and ZMI operations like undo.

It also happens when you rename a page, reusing the name of a previously-deleted page B with a longer revision history. The histories become tangled, and I don't have a smart idea to handle this case.

Here is a simple idea which should at least avoid breakage: on saving a revision and finding that the revision object with this id already exists, pick a new revision number that is greater than all the existing ones. If you think of a better solution, please post.

fragility --simon, Sun, 03 Jun 2007 12:43:48 -0700 reply

Fixed in darcs.

fragility --wlang, Mon, 04 Jun 2007 07:11:06 -0700 reply

> It also happens when you rename a page, reusing the name of a
> previously-deleted page B with a longer revision history. The
> histories become tangled, and I don't have a smart idea to
> handle this case.

We could make the Wikipages "folderish" and store the revisions in it. Thus the revisions stick with renamed pages. But i think this change would be too big...

fragility --Simon Michael, Mon, 04 Jun 2007 14:06:32 -0700 reply

Hmm, that seems a good idea. What could possibly go wrong ?

fragility --EmmaLaurijssens, Mon, 04 Jun 2007 14:29:51 -0700 reply

Don't know. There are other advantages as well, like keeping images and attachments with the page that links to them, and subpages, which make MediaWiki?-style tabs possible. Featuritis? Maybe. Maybe not.

done --simon, Wed, 01 Aug 2007 07:29:20 -0700 reply

Status: open => closed

I fixed a robustness issue yesterday. Generally this has been working well, and there's no proof #1335 is related, so I'll mark it closed. Storing revisions within each page is a good followup idea we should try.