It's got couple of FIXMEs, and a very site-specific filter for recentchanges. Not sure how to do that better though. I will eventually add web commits, probably of my own (and mention it here).
+---
+
+And here's yet another one, including an updated `ikiwiki-makerepo`. :)
+
+<http://khjk.org/~pesco/ikiwiki-darcs/> (now a darcs repo)
+
+> Note that there's a 'darcs' branch in git that I'm keeping a copy of your
+> code in. Just in case. :-)
+
+I've taken all the good stuff from the above and added the missing hooks. The code hasn't seen a lot of testing, so some bugs are likely yet to surface. Also, I'm not experienced with perl and don't know where I should have used the function `possibly_foolish_untaint`.
+
+Regarding the repository layout: There are two darcs repositories. One is the `srcdir`, the other we'll call `master`.
+
+ * HTML is generated from `srcdir`.
+ * CGI edits happen in `srcdir`.
+ * The backend pulls updates from `master` into `srcdir`, i.e. darcs commits should happen to `master`.
+ * `master` calls ikiwiki (through a wrapper) in its apply posthook, i.e. `master/_darcs/prefs/defaults` should look like this:
+
+ apply posthook ikiwrap
+ apply run-posthook
+
+ (I'm not sure, should/could it be `ikiwrap --refresh` above?)
+ * The backend pushes CGI edits from `srcdir` back into `master` (triggering the apply hook).
+ * The working copies in `srcdir` and `master` should *not* be touched by the user, only by the CGI or darcs, respectively.
+
+> Review of this one:
+>
+> * Should use tab indentation.
+> * `rcs_getctime` should not need to use a ctime cache (such a cache should
+> also not be named `.ikiwiki.ctimes`). `rcs_getctime` is run exactly
+> once per page, ever, and the data is cached in ikiwiki's index.
+> * I doubt that ENV{DARCS} will be available, since the wrapper clobbers> the entire
+> environment. I'd say remove that.
+> * I don't understand what `darcs_info` is doing, but it seems to be
+> parsing xml with a regexp?
+> * Looks like `rcs_commit` needs a few improvements, as marked TODO
+> * `rcs_remove` just calls "rm"? Does darcs record notice the file was removed
+> and automatically commit the removal? (And why `system("rm")` and not
+> `unlink`?)
+> * Is the the darcs info in [[details]] still up-to-date re this version?
+> --[[Joey]]
+
+> Update:
+>
+> I think I've addressed all of the above except for the XML parsing in `darcs_info`.
+> The function determines the md5 hash of the last patch the given file appears in.
+> That's indeed being done with regexps but my Perl isn't good enough for a quick recode
+> right now.
+>
+> As for the darcs info in [[rcs/details]], it does not accurately describe the way
+> this version works. It's similar, but the details differ slightly.
+> You could copy my description above to replace it.
+>
+> There is still some ironing to do, for instance the current version doesn't allow for
+> modifying attachments by re-uploading them via CGI ("darcs add failed"). Am I assuming
+> correctly that "adding" a file that's already in the repo should just be a no-op?
+> --pesco
+
+>> It should result in the new file contents being committed by
+>> `rcs_commit_staged`. For some revision control systems, which
+>> automatically commit modifications, it would be a no-op. --[[Joey]]
+
+>>> Done. --pesco
+
[[!tag patch]]