X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/d7b434be8c65cb81805f921fcdbdbc352141e469..6c584a00de76e3193cc514572974e8ae99212e9c:/doc/post-commit/discussion.mdwn?ds=sidebyside

diff --git a/doc/post-commit/discussion.mdwn b/doc/post-commit/discussion.mdwn
index 85853c945..fc0a27ee4 100644
--- a/doc/post-commit/discussion.mdwn
+++ b/doc/post-commit/discussion.mdwn
@@ -73,12 +73,30 @@ proper order. (cvs add isn't recursive, sadly.)
 
 Can you offer an educated guess what's going wrong here? --[[Schmonz]]
 
-> Got `rcs_recentchanges` working, believe it or not, thanks to
-> [cvsps](http://www.cobite.com/cvsps/). If I can figure out this
-> interaction between the post-commit hook and `cvs add` on directories,
-> the CVS plugin is mostly done. Could it be a locking issue? Where should
-> I be looking? Any suggestions appreciated. --[[Schmonz]]
-
+> Got `rcs_recentchanges` working, believe it or not, thanks to [cvsps](http://www.cobite.com/cvsps/). If I can figure out this interaction between the post-commit hook and `cvs add` on directories, the CVS plugin is mostly done. Could it be a locking issue? Where should I be looking? Any suggestions appreciated. --[[Schmonz]]
+
+>> Okay, it is definitely a locking issue. First, on the conjecture that
+>> `cvs add <directory>` was triggering the post-commit hook and confusing
+>> ikiwiki, I wrapped the ikiwiki post-commit binary with a shell script
+>> that exited 0 if the triggering file was a directory. The first half of
+>> the conjecture was correct -- my wrapper got triggered -- but the web
+>> add of `one/two/three.mdwn` (where `one` and `two` weren't existing
+>> CVS-controlled dirs) remained hung as before. There were two ikiwiki
+>> processes running. On a whim, I killed the one with the higher PID; `cvs
+>> add one` immediately completed successfully, then back to a hang and two
+>> ikiwiki processes. I killed the newer one again and then `cvs add
+>> one/two` and `cvs add one/two/three.mdwn` completed and the web add was
+>> successful. --[[Schmonz]]
+
+>>> Aaaaaand I was wrong about the second half of the conjecture being
+>>> wrong. The wrapper script wasn't correctly identifying directories;
+>>> with that fixed, everything works. I've created a
+>>> [[rcs/cvs]] page. Thanks for listening. :-)
+>>> --[[Schmonz]]
+
+>> Here is a comment I committed to my laptop from Madrid Airport before
+>> your most recent updates, in case it's still useful:
+>>
 >> Locking certianly seems likely to be a problem. ikiwiki calls `rcs_add`
 >> *before* disabling the post-commit plugin, since all over VCS allow
 >> adding something in a staged manner. You can see this in, for example,
@@ -97,3 +115,9 @@ Can you offer an educated guess what's going wrong here? --[[Schmonz]]
 >> especially since ikiwiki always commits after an add, in the same
 >> process, so you could just use a temporary list of things to add.
 >> --[[Joey]] 
+
+>>> Thanks for the comments. Attempting to set up a wiki on a different system with a different version of `cvs`, I've encountered a new locking problem within CVS: `cvs commit` takes a write lock, post-commit ikiwiki calls `rcs_update()`, `cvs update` wants a read lock and blocks. The easiest fix I can think of is to make `cvs commit` return and relinquish its lock -- so instead of my wrapper script `exec`ing ikiwiki's post-commit hook, I amp it off and exit 0. Seems to do the trick and, if I grok ikiwiki's behavior here, is not dangerous. (Beats me why my development `cvs` doesn't behave the same WRT locking.)
+
+>>> I was all set to take your third suggestion, but now that there's more than one CVS oddity fixed trivially in a wrapper script, I think I prefer doing it that way.
+
+>>> I'd be glad for the CVS plugin to be included in ikiwiki, if and when you deem it ready. Please let me know what needs to be done for that to happen. --[[Schmonz]]