The XHTMLValidator (just against the w3c DTDs) is now somewhat packaged up and is in SVN. I switched from using a catalog file to using a trivial hand-written entity resolver as it still seemed to be going to the web when access was available, explaining why the tests were sometimes very slow.

====[2008-04-17] NightlyBuilds now available

Erm that's it really.

http://downloads.reviki.org/nightly/

====[2008-04-15] ConfigAutoProperties

I'm working on addressing one of the attachment related stories for the 1.0 release.

The plan is to add ConfigAutoProperties which will be a text page containing the contents of the [auto-props] section of the svn config file. These will be used for new attachments.

This ought to make browsing the SVN repository directly more pleasing. The common practical problem is that the PDF files are incorrectly added as to SVN as text (as they often are for the first few bytes until you hit a compressed stream).

I'll also address using these mime types at attachment download time too (I think we currently always set application/octet-stream).

**Update (r720):** We now have ConfigAutoProperties with some default content to be documented on AboutConfigAutoProperties. Decided there's no point setting mime-type on download because the current behaviour results in the browser / OS mime-type mappings being used which is probably more comprehensive. Will gladly revisit if anyone has a use case.

====[2008-03-31] XHTML validation

So it turns out this page is --horribly, horribly invalid-- finally [[http://validator.w3.org/check?uri=http%3A%2F%2Freviki.org%2Fpages%2Freviki%2FDevLog&charset=%28detect+automatically%29&doctype=Inline&group=0|valid]] as of r682.

Time to find a validator I can hook into the HtmlUnit functional tests and the unit tests for the renderer.

**Update (r660)**:
* We have XHTML DTD validation hooked into the functional tests. Surprisingly slow though, even with catalog remappings for the W3C DTDs.
* This page is valid except for an issue with ul elements generated by the renderer.

The title revision is the last changed revision, rather than the accessed revision. As it was it just wasn't useful information, now you can get some idea of how old a page is. One problem common to all forms of documentation is parts inevitably get stale. It's good to have a visual indication of how recently the page has been updated. Perhaps for that reason the last changed date / user should be more visible...

====[2008-03-30] Atomic commit for adding attachment and link (r629)

For a while now we've had uploading an attachment split across two commits, one creating the {{{PageName-attachments}}} directory (if requried) and the other committing the attachment file. As of r619 it got worse - we now automatically add a link to the attachment to the associated page.

Time to tidy SVNPageStore/BasicSVNOperations to make it easy to create the directory and the file in the same commit. This will be needed for RefactorRename too.

**Update r629:** The mutator methods on BasicSVNRepository now do less to give the SVNPageStore more control over combining modifications. All the operations needed to upload an attachment are now a single commit. Having to assemble all the actions up-front - because SVNRepository isn't re-entrant - leads to a clumsy separation of figuring out if something needs to be done and doing it - suspect we could pull out a prepare / perform interface. Revisit for RefactorRename.