X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/f012c9d795e1c1688d29e23074d71c3eba1824d1..ca9e45c3ba2ad852123aeb8783eed07ed73ce00c:/doc/todo/mercurial.mdwn diff --git a/doc/todo/mercurial.mdwn b/doc/todo/mercurial.mdwn index 0a20dd5b0..f0dbf9806 100644 --- a/doc/todo/mercurial.mdwn +++ b/doc/todo/mercurial.mdwn @@ -1,5 +1,61 @@ -* Need to get post commit hook working (or an example of how to use it.) -* rcs_notify is not implemented * Is the code sufficiently robust? It just warns when mercurial fails. * When rcs_commit is called with a $user that is an openid, it will be passed through to mercurial -u. Will mercurial choke on this? + * Nope. Mercurial doesn't expect any particular format for the username, + though "Name
" is standard. --[[bma]] +* The way `-u $user` is passed to `hg commit`, there's no way to tell + if a given commit came in over the web or was done directly. So + rcs_recentchanges hardcodes 'committype => "mercurial"'. See the monotone + backend for an example of one that does this right. +* The rcs_commit implementation seems not to notice if the file has been + changed since a web edit started. Unlike all the other frontends, which + use the rcstoken to detect if the web commit started editing an earlier + version of the file, and if so, merge the two sets of changes together. + It seems that with the current mercurial commit code, it will always + blindly overwrite the current file with the web edited version, losing + any other changes. + +Posthook: in `$srcdir/.hg/hgrc`, I have the following + + [hooks] + incoming.update = hg up + update.ikiwiki = ikiwiki --setup /path/to/ikiwiki.setup --refresh + +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.) + +> Try running it with --post-commit instead of --refresh. That should +> work better, handling both the case where the edit was made via the web +> and then committed, and the case where a commit was made directly. +> It can deadlock if the post-commit hook runs with --refresh in the +> former case. --[[Joey]] + +*** + +I have a few notes on mercurial usage after trying it out for a while: + +1. I have been using ikiwiki's `--post-commit` option without apparent problems. I'm the only current user of my wiki, though. + +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: + + # Mercurial stuff. + rcs => "mercurial", + historyurl => "http://localhost/cgi-bin/hgwebdir.cgi/ikiwiki/log/tip/\[[file]]", + diffurl => "http://localhost/cgi-bin/hgwebdir.cgi/ikiwiki/diff/tip/\[[file]]", + +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? + +--buo + +> No, those files should not be added to revision control. --[[Joey]] + +>> OK. I see two problems: + +>> 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. + +>>> The history is stored in mercurial. How will it be lost? + +>> 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`. + +>> I think the ideal solution would be to build `$destdir/recentchanges/*` directly from the output of `hg log`. --[[buo]] + +>>>> That would be 100 times as slow, so I chose not to do that. --[[Joey]]