Anthony Towns has a new blog, and he makes a pretty reasonable and interesting Blosxom suggestion
I think what would be nice is having blosxom see the files,
-rw-r--r-- 1 aj aj 323 May 25 20:29 foo.txt
-rw-r--r-- 1 aj aj 80 May 26 13:10 foo.txt-1
-rw-r--r-- 1 aj aj 103 May 26 14:40 foo.txt-2
and magically translate that into an original entry, with two dated updates. You could then mark the files as uneditable once you've finished writing them, and not worry about accidently revising history.
A simple version of this would be pretty easy -- a plugin with a story() handler that looks for the -## files and just appends them, with an "Update ...:" header.
There are some interesting questions though about how it should act in the face of date sorting and specification; when showing index.html, should foo be listed as May 25 20:29 or May 26 14:40 (the former would be easier; the latter would be doable by supplying an entries()). When showing /2003/05/25 what should be shown? How about /2003/05/26?
that would be SO COOL! so, you gonna implement it?? :)
But I would do it the other way around, possibly by using a revised wikieditish plugin ? Anyway, imho foo-2.txt should be the oldest, and foo.txt the newest. Oh, and maybe not .txt but .rev or so.
It seems less error prone & more zen-of-blosxomy to add updates by creating new files than by renaming all the old ones and creating a new one with the same name as the next-most-recent.
I think whenever you look at one of the entries, you ought to see links to the others, because people would like to see context. There’s no requirement that 2003/05/25 show you exactly what existed at that date; showing forward links would be highly useful.
Looking at a date ought to show all the story-revisions for that date.
I think I would lean towards calling them foo-1.txt, or perhaps foo.1.txt. emacs and myself are fans of consistent extensions. :-)
Another nice feature of that approach would be that if you viewed the same story tree in a version of blosxom without this plugin, then everything would still work, but the stories would just come up as unrelated.
I agree that cascading renames are not unixy.
I’ve been assuming that the later posts would be “further thoughts on the same topic”, but sometimes it would be nice to be able to revise the whole thing. But you don’t want it to disappear from the original date. You might, or might not, want people to be able to retrieve earlier versions, or see visual diffs. (Feep feep feep).
see “here:”http://azure.humbug.org.au/~aj/blog/2003/08/17 for my implementation. seems to work.
Sorry, comments are currently disabled. They'll be returning shortly, if all goes according to plan.