Re: moving to a git-backed wiki

> 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/>
>
>