Karl Billeter wrote:
On Mon, Jul 30, 2012 at 11:55:09PM +1000, Trent W. Buck wrote:
ikiwiki, gitit, moin, mediawiki -- in that order.
Actually, top of the list would be a git repo of reStructured Text and a makefile to churn out read-only static HTML. (Not a "wiki", in the c2 sense.)
I keep meaning to look at gollum one day (https://github.com/github/gollum) but it fails your static requirement.
Meh. Looks like yet another NIH wiki. FWIW my requirements were/are: - MUST be dvcs-backed (SHOULD be git) MUST be able to make updates via the vcs. - SHOULD be reST (and thus SHOULD support PDF output) - SHOULD support a "dumb" static httpd via a make-style post-compile pass. - MAY support optional editing via a "smart" httpd with some kind of in-browser edit screen. - other shiny features, like tags, cross-references, indices, in-browser body searching (cf. git clone & grep) are OPTIONAL. Currently in the office we're using gitit, because management upgraded edit-via-browser to MUST and gitit has better reST support than ikiwiki... except that experience has shown that the haskell implementation of reST is pretty ordinary compared to the reST spec, or the Python implementation thereof. For my personal stuff I just have a bunch of .txt reST docs in doc/ in my dotfile repo, which technically has a makefile to render to PDF and HTML, but I haven't bothered to use for years -- I just link to the .txt version. For professional documents (like product manuals), I've nearly convinced management to use git+sphinx[*] instead of ODF. Which is a Super Nice thing. [*] sphinx is docutils plus some large/complex document extensions, and vastly better default .sty and .css stylesheets. http://sphinx.pocoo.org