X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/3f33d3979c89610e1c8514c71c887acfa1c3ccac..04498cdeb486a518ef9ed2464cb95f734b48c6bd:/doc/bugs/post-commit_hangs.mdwn

diff --git a/doc/bugs/post-commit_hangs.mdwn b/doc/bugs/post-commit_hangs.mdwn
index c28a34040..32820d886 100644
--- a/doc/bugs/post-commit_hangs.mdwn
+++ b/doc/bugs/post-commit_hangs.mdwn
@@ -10,6 +10,37 @@ I installed ikiwiki v3.14159 in /usr/local from tarball (/usr contains an older
 >> Hmm, maybe it's the recursive call to ikiwiki which is the problem.
 >> The underlying VCS is mercurial. --Ali
 
+>>> You're not supposed to run ikiwiki -setup manually in your post commit hook.
+>>> Doing so will certianly lead to a locking problem; it also forces ikiwiki to rebuild
+>>> the entire wiki anytime a single page changes, which is very inefficient!
+>>>
+>>> Instead, you should use the `mercurial_wrapper` setting
+>>> in the setup file, which will make ikiwiki generate a small
+>>> executable expressly designed to be run at post commit time.
+>>> Or, you can use the `--post-commit` option, as documented
+>>> in [[rcs/mecurial]] --[[Joey]] 
+
+>>>> I don't run ikiwiki --setup in the commit hook; I run ikiwiki --post-commit (as mentioned above).
+>>>> I'm trying to run ikiwiki --setup from the command line after modifying the setup file.
+>>>> ikiwiki --setup is calling hg update, which is calling ikiwiki --post-commit. Am I not supposed to do that? --Ali
+
+>>>>> No, I don't think that hg update should call ikiwiki anything. The
+>>>>> [[hgrc_example|rcs/mercurial]] doesn't seem to configure it to do that? --[[Joey]] 
+
+>>>>>> Ok, I'm not sure I understand what's going on, but my problem is solved.
+>>>>>>
+>>>>>> My hgrc used to say:
+>>>>>>
+>>>>>> [hooks]
+>>>>>>
+>>>>>> incoming.update = hg up
+>>>>>>
+>>>>>> update.ikiwiki = ikiwiki --setup /home/ikiwiki/ikiwiki.setup --post-commit
+>>>>>>
+>>>>>> I've now changed it to match the example page and it works. Thanks --Ali.
+
+>>>>>>> [[done]]
+
 > Also, how have you arranged to keep it from seeing the installation in /usr? Perl could well be loading
 > modules from the old installation, and if it's one with a different locking strategy that would explain your problem. --[[Joey]]