Jeff King wrote: > If it sounds like I'm handwaving away scalability problems, I am. I'd be > curious to see some performance numbers for gollum or ikiwiki versus > more traditional wiki formats. Ikiwiki builds static pages, this tends to mean it doesn't have performance, because there is little more to perform than httpd < file > network :) So I've routinely had ikiwiki sites slashdotted, and not noticed. Ikiwiki is not enormously fast in the rare cases when it does have to run as a CGI, but little of that has to do with git. About the worst case is that saving a page edit leads to a git commit -- if git decides to gc the repository right then, it could make the save stall for a while. There are easy ways to avoid that. (ie, git gc in cron job) In general, though ikiwiki as a CGI is fast enough to not be annoying -- although it won't scale to a site the size of wikipedia. Since I'm lazy, ikiwiki does not include a history or diff viewer. It just points off to gitweb or a similar tool. As you say, gitweb can be fast enough, and really most wiki users do read their current content, or maybe make an edit; digging in the history is comparatively rare. And once users realize the wiki is in git, they can use gitk to dig in the history without using any server resources. :) The feature I like best with using git for a wiki (besides ease of branching) is that it can actually make a legitimate use of the woefully underused git push over git:// feature. Ikiwiki can be configured to check such pushes, running via the pre-receive hook. This allows it to limit the changes that can be pushed anonymously to changes that could be made using the web interface. So if you've chosen to lock some pages, or virus filter attachments, or whatever, in the web side of the wiki, that all applies to the anonymous git pushes too. Details at <http://ikiwiki.info/tips/untrusted_git_push/> -- see shy jo
Attachment:
signature.asc
Description: Digital signature