doc/todo/mercurial.mdwn

   1 * Need to get post commit hook working (or an example of how to use it.)
   2   * See below. --[[bma]]
   3 * rcs_notify is not implemented (not needed in this branch --[[Joey]])
   4 * Is the code sufficiently robust? It just warns when mercurial fails.
   5 * When rcs_commit is called with a $user that is an openid, it will be
   6   passed through to mercurial -u. Will mercurial choke on this?
   7  * Nope. Mercurial doesn't expect any particular format for the username,
   8    though "Name <address@domain>" is standard. --[[bma]]
   9 * The way `-u $user` is passed to `hg commit`, there's no way to tell
  10   if a given commit came in over the web or was done directly. So
  11   rcs_recentchanges hardcodes 'committype => "mercurial"'. See the monotone
  12   backend for an example of one that does this right.
  13 * The rcs_commit implementation seems not to notice if the file has been
  14   changed since a web edit started. Unlike all the other frontends, which
  15   use the rcstoken to detect if the web commit started editing an earlier
  16   version of the file, and if so, merge the two sets of changes together.
  17   It seems that with the current mercurial commit code, it will always
  18   blindly overwrite the current file with the web edited version, losing
  19   any other changes.
  20
  21 Posthook: in `$srcdir/.hg/hgrc`, I have the following
  22
  23     [hooks]
  24     incoming.update = hg up
  25     update.ikiwiki = ikiwiki --setup /path/to/ikiwiki.setup --refresh
  26
  27 This should update the working directory and run ikiwiki every time a change is recorded (someone who knows mercurial better than I do may be able to suggest a better way, but this works for me.)
  28
  29 > Try running it with --post-commit instead of --refresh. That should
  30 > work better, handling both the case where the edit was made via the web
  31 > and then committed, and the case where a commit was made directly.
  32 > It can deadlock if the post-commit hook runs with --refresh in the
  33 > former case. --[[Joey]]
  34
  35 ***
  36
  37 I have a few notes on mercurial usage after trying it out for a while:
  38
  39 1. I have been using ikiwiki's `--post-commit` option without apparent problems. I'm the only current user of my wiki, though.
  40
  41 1. The `ikiwiki.setup` file included in ikiwiki works with mercurial's `hgserve`, which is not the preferred solution. Mercurial's `hgwebdir.cgi` is more flexible and doesn't require running a server. I have this in my .setup file:
  42
  43         # Mercurial stuff.
  44         rcs => "mercurial",
  45         historyurl => "http://localhost/cgi-bin/hgwebdir.cgi/ikiwiki/log/tip/\[[file]]",
  46         diffurl => "http://localhost/cgi-bin/hgwebdir.cgi/ikiwiki/diff/tip/\[[file]]",
  47
  48 1. I have noticed that running `ikiwiki` after a change to the wiki adds files to a directory called `recentchanges` under `$srcdir`. I don't understand why such files are needed; worse, they are not added to mercurial's list of tracked files, so they polute the output of `hg log`. Is this a bug? Should mercurial's commit hook be modified to add these files before the commit?
  49
  50 --buo
  51
  52 > No, those files should not be added to revision control. --[[Joey]]
  53
  54 >> OK. I see two problems:
  55
  56 >> 1. If I clone my wiki, I won't get an exact copy of it: I will lose the recentchanges history. This could be an acceptable limitation but IMO this should be documented.
  57
  58 >>> The history is stored in mercurial. How will it be lost?
  59
  60 >> 2. The output of `hg status` is polluted. This could be solved trivially by adding a line containing `recentchanges` to `.hgignore`. Another alternative would be to store the `recentchanges` directory inside `$srdcir/.ikiwiki`.
  61
  62 >> I think the ideal solution would be to build `$destdir/recentchanges/*` directly from the output of `hg log`. --[[buo]]
  63
  64 >>>> That would be 100 times as slow, so I chose not to do that. --[[Joey]]