d3d3999410
This speeds up web commits by 1/4th of a second or so, since perl does not have to start up for the post commit hook. perl's locking is completly FuBar, since it's impossible to tell what perl flock() really does, and thus difficult to write code in other languages that interoperates with perl's locking. (Let alone interoperating with existing fcntl locking from perl...) In this particular case, I think I was able to find a way to avoid the insanity, mostly. The C code does a true flock(2), and if perl is using an incompatable lock method that does not use the same locking primative at the kernel level, then the C code's test will fail, and it will go ahead and run the perl code. Then the perl code's test will test the right thing. On Debian, at least lately, perl's flock() does a true flock(2), so the optimisation does work. |
||
|---|---|---|
| .. | ||
| .gitignore | ||
| NEWS | ||
| README.Debian | ||
| changelog | ||
| compat | ||
| control | ||
| copyright | ||
| examples | ||
| postinst | ||
| preinst | ||
| rules | ||
README.Debian
It's a good idea, and in some cases a requirement, to rebuild your wikis when upgrading to a new version of ikiwiki. If you have a lot of different wikis on a system, this can be a pain to do by hand, and it's a good idea to automate it anyway. This Debian package of ikiwiki supports rebuilding wikis on upgrade. It will run ikiwiki-mass-rebuild if necessary when upgraded. The file /etc/ikiwiki/wikilist lists the setup files of wikis to rebuild, as well as the user who owns the wiki. Edit this file and add any wikis you set up. You can also allow users to maintain their own list of wikis to rebuild, by listing their usernames in /etc/ikiwiki/wikilist without corresponding setup files. ikiwiki will then read their lists of wikis from .ikiwiki/wikilist in their home directories. The examples directory contains the source to some example wiki setups.