doc/post-commit/discussion.mdwn

   1 Hi Joey and many thanks for your work on ikiwiki, as usual you give us a very good soft...
   2
   3 I want to be able to edit my website from a navigator (with the CGI) and
   4 from my favorite editor on my laptop. I have managed to use the subversion wrapper
   5 so I have write a post-commit hook with :
   6
   7     cd /~/wikisrc/
   8     svn up
   9     /usr/bin/ikiwiki --setup ../ikiwiki.setup
  10
  11 at the end.
  12
  13 This configuration works for me, the svn wrapper doesn't seems to
  14 do the svn up stuff so I wonder if I've missed something...
  15
  16 Regards.
  17
  18 > Well, you've created a post-commit script that runs ikiwiki in setup mode.
  19 > That's not how it's generally done, instead you generally configure
  20 > ikiwiki to generate a post-commit _binary_ that runs ikiwiki in update
  21 > mode. That binary can be installed directly as the post-commit hook, or
  22 > called from an existing post-commit hook script, and it will handle the
  23 > necessary svn up, and will update the wiki much quicker than your --setup
  24 > command above (which rebuilds the entire wiki and all wrappers each
  25 > commit)!
  26 >
  27 > In this wiki's setup file, I configure ikiwiki to generate a post-commit
  28 > wrapper binary like so:
  29 >
  30 >       wrappers => [
  31 >       {
  32 >               wrapper => "/srv/svn/ikiwiki/hooks/post-commit",
  33 >               wrappermode => "04755",
  34 >               notify => 1,
  35 >       }
  36 >       ],
  37
  38
  39 Hello, I've setup ikiwiki with subversion. I can edit pages from web browser using CGI and, when I go to recentchanges, it shows that modification with "web" word. But, if I modify any .mdwn file, it gets updated in website but it doesn't show in recentchanges entry with "svn" word. If I run "svn ci -m changes", it shows in recentchanges correctly.
  40
  41 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.
  42
  43 Thanks
  44
  45 > Yes, ikiwiki does expect you to use your revision control system to check
  46 > in changes. Otherwise, recentchanges cannot work right, since it uses the
  47 > commit history from your revision control system. --[[Joey]]
  48
  49 -----
  50
  51 I'm working on an [[rcs]] plugin for CVS, adapted from `svn.pm`, in order
  52 to integrate ikiwiki at sites where that's all they've got. What's working
  53 so far: web commit (post-commit hook and all), diff, add (under certain
  54 conditions), and remove. What's not working: with rcs_add(), iff any of the
  55 new page's parent dirs aren't already under CVS control and the post-commit
  56 hook is enabled, the browser and ikiwiki stall for several seconds trying
  57 to add it, then time out. (If I kill ikiwiki when this is happening, it cvs
  58 adds the topmost parent that needed adding; if I wait for timeout, it
  59 doesn't. I think.) If I disable the post-commit hook and do the same kind
  60 of thing, the page is created and saved.
  61
  62 In case you're lucky enough not to know, cvs adds on directories are weird
  63 -- they operate immediately against the repository, unlike file adds:
  64
  65     $ cvs add randomdir
  66     Directory /Users/schmonz/Documents/cvswiki/repository/ikiwiki/randomdir added to the repository
  67
  68 I was able to work out that when I'm seeing this page save misbehavior, my
  69 plugin is somewhere inside `system("cvs", "-Q", "add", "$file")`, which was
  70 never returning. If I changed it to anything other than cvs it iterated
  71 correctly over all the parent dirs which needed to be added to CVS, in the
  72 proper order. (cvs add isn't recursive, sadly.)
  73
  74 Can you offer an educated guess what's going wrong here? --[[Schmonz]]
  75
  76 > 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]]
  77
  78 >> Okay, it is definitely a locking issue. First, on the conjecture that
  79 >> `cvs add <directory>` was triggering the post-commit hook and confusing
  80 >> ikiwiki, I wrapped the ikiwiki post-commit binary with a shell script
  81 >> that exited 0 if the triggering file was a directory. The first half of
  82 >> the conjecture was correct -- my wrapper got triggered -- but the web
  83 >> add of `one/two/three.mdwn` (where `one` and `two` weren't existing
  84 >> CVS-controlled dirs) remained hung as before. There were two ikiwiki
  85 >> processes running. On a whim, I killed the one with the higher PID; `cvs
  86 >> add one` immediately completed successfully, then back to a hang and two
  87 >> ikiwiki processes. I killed the newer one again and then `cvs add
  88 >> one/two` and `cvs add one/two/three.mdwn` completed and the web add was
  89 >> successful. --[[Schmonz]]
  90
  91 >>> Aaaaaand I was wrong about the second half of the conjecture being
  92 >>> wrong. The wrapper script wasn't correctly identifying directories;
  93 >>> with that fixed, everything works. I've created a
  94 >>> [[rcs/cvs]] page. Thanks for listening. :-)
  95 >>> --[[Schmonz]]
  96
  97 >> Here is a comment I committed to my laptop from Madrid Airport before
  98 >> your most recent updates, in case it's still useful:
  99 >>
 100 >> Locking certianly seems likely to be a problem. ikiwiki calls `rcs_add`
 101 >> *before* disabling the post-commit plugin, since all over VCS allow
 102 >> adding something in a staged manner. You can see this in, for example,
 103 >> `editpage.pm` lines 391+.
 104 >>
 105 >> So I guess what happens is that ikiwiki has taken the wiki lock, calls
 106 >> `rcs_add`, which does a `cvs add`, which runs the post commit hook,
 107 >> since it is not disabled -- which blocks waiting for the wiki lock.
 108 >>
 109 >> I guess you can fix this in either of three ways: Modify lots of places
 110 >> in ikiwiki to disable the post commit hook before calling `rcs_add`,
 111 >> or make cvs's `rcs_add` temporarily disable the commit hook and
 112 >> re-enable it (but only if it was not already disabled, somehow),
 113 >> or make cvs's `rcs_add` only make note that it needs to call `cvs add`
 114 >> later, and do so at `rcs_commit`. The last of these seems easist,
 115 >> especially since ikiwiki always commits after an add, in the same
 116 >> process, so you could just use a temporary list of things to add.
 117 >> --[[Joey]]
 118
 119 >>> 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.)
 120
 121 >>> 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.
 122
 123 >>> 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]]