X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/719c886cec57878f477cb9cd1c1ad21e3c65739f..43a88daa5fc23fb70c22ab4472dd293e04b7236d:/doc/post-commit/discussion.mdwn?ds=inline diff --git a/doc/post-commit/discussion.mdwn b/doc/post-commit/discussion.mdwn index 08125d9ff..fc0a27ee4 100644 --- a/doc/post-commit/discussion.mdwn +++ b/doc/post-commit/discussion.mdwn @@ -41,3 +41,83 @@ Hello, I've setup ikiwiki with subversion. I can edit pages from web browser usi So, I think I miss something, because I don't think I must run "svn add" or "svn commit" anytime I modify or create a wiki file. Thanks + +> Yes, ikiwiki does expect you to use your revision control system to check +> in changes. Otherwise, recentchanges cannot work right, since it uses the +> commit history from your revision control system. --[[Joey]] + +----- + +I'm working on an [[rcs]] plugin for CVS, adapted from `svn.pm`, in order +to integrate ikiwiki at sites where that's all they've got. What's working +so far: web commit (post-commit hook and all), diff, add (under certain +conditions), and remove. What's not working: with rcs_add(), iff any of the +new page's parent dirs aren't already under CVS control and the post-commit +hook is enabled, the browser and ikiwiki stall for several seconds trying +to add it, then time out. (If I kill ikiwiki when this is happening, it cvs +adds the topmost parent that needed adding; if I wait for timeout, it +doesn't. I think.) If I disable the post-commit hook and do the same kind +of thing, the page is created and saved. + +In case you're lucky enough not to know, cvs adds on directories are weird +-- they operate immediately against the repository, unlike file adds: + + $ cvs add randomdir + Directory /Users/schmonz/Documents/cvswiki/repository/ikiwiki/randomdir added to the repository + +I was able to work out that when I'm seeing this page save misbehavior, my +plugin is somewhere inside `system("cvs", "-Q", "add", "$file")`, which was +never returning. If I changed it to anything other than cvs it iterated +correctly over all the parent dirs which needed to be added to CVS, in the +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]] + +>> Okay, it is definitely a locking issue. First, on the conjecture that +>> `cvs add ` 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, +>> `editpage.pm` lines 391+. +>> +>> So I guess what happens is that ikiwiki has taken the wiki lock, calls +>> `rcs_add`, which does a `cvs add`, which runs the post commit hook, +>> since it is not disabled -- which blocks waiting for the wiki lock. +>> +>> I guess you can fix this in either of three ways: Modify lots of places +>> in ikiwiki to disable the post commit hook before calling `rcs_add`, +>> or make cvs's `rcs_add` temporarily disable the commit hook and +>> re-enable it (but only if it was not already disabled, somehow), +>> or make cvs's `rcs_add` only make note that it needs to call `cvs add` +>> later, and do so at `rcs_commit`. The last of these seems easist, +>> 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]]