Derek,
As Carl suggests, that is the default behaviour on 5.0 HEAD (sort of).
Currently, there are actually (for better or worse) two "interfaces" to the file versions in File Storage.
In your example above, if you change the request
... download/termclear.html
to
... view/termclear.html
it should get processed by the new index.vuh file I added in order to make pretty URLs (and, consequently, relative linking of images, pages, etc. in HTML documents) work.
In File Storage (on HEAD), the ordinary links to files point with their relative paths (pretty URLs) to the "view" dir, and the index.vuh thereunder will make sure it returns the *live* revision (not necesserily the latest, although that is currently the case in FS) of the file wrapped in a template if it is of text/* MIME media type.
The file icons to the left of the links, OTOH, point to the good old "download" dir which depends on a version_id query var. I left it this way so that folks should be able to choose between templating or not when they download a file, and because there is a speed penalty associated with the "pretty URL" / templating approach.
Of course, neither templating nor pretty URLs will work in the download dir case. Neither will they work in the "view details" page, which also uses the "download" approach.
The "view details" page is for revision management and even if someone would expect it to work as the live revision browser on the main page there is, to the best of my knowledge, no way to determine which version of an (imagined) image in revision X of a certain HTML page should be shown... I don't think it makes any sense to simply assume it will be the live revision of that image.
But I'm sure there may people with other opinions and suggestions/solutions as to how that may be solved (if it is even conceived as a problem, that is). If I'm not mistaken, Talli is working on a usability study of the FS for Sloan. Let's hear with him what he has to say ... right, Talli?
