X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/ba96fb16bea4eee03d394d7d12b7e94295932a80..d93ae5a0fc452deff493506ec5a040fb699ba9d5:/doc/todo/mercurial.mdwn?ds=inline diff --git a/doc/todo/mercurial.mdwn b/doc/todo/mercurial.mdwn index e3fa70bc4..de1f148e5 100644 --- a/doc/todo/mercurial.mdwn +++ b/doc/todo/mercurial.mdwn @@ -1,6 +1,3 @@ -* Need to get post commit hook working (or an example of how to use it.) - * See below. --[[bma]] -* rcs_notify is not implemented (not needed in this branch --[[Joey]]) * 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? @@ -17,6 +14,10 @@ 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. +* `rcs_commit_staged`, `rcs_rename`, `rcs_remove`, and `rcs_diff` are not + implemented for mercurial, and so attachments, remove and rename plugins + and recentchangesdiff cannot be used with it. (These should be fairly + easy to add..) Posthook: in `$srcdir/.hg/hgrc`, I have the following @@ -32,6 +33,62 @@ This should update the working directory and run ikiwiki every time a change is > It can deadlock if the post-commit hook runs with --refresh in the > former case. --[[Joey]] +The problem with --post-commit is that if you delete some pages in $SRC, ikiwiki --setup setupfile --post-commit will not delete them in $DEST. --[[users/weakish]] + +> You should really be using a setup file that has `mercurial_wrapper` +> set, and running the wrapper generated by that from your hook. +> That will work. I think that the `--setup --post-commit` on the command +> line is currently broken and does the same expensive rebuild process as --setup +> alone (which doesn't delete files from $DEST either). Will fix that. +> (fixed) +> --[[Joey]] + +>> Mercurial doesn't support put hooks in .hg/hooks/* (like git). In Mercurial, the only way to run +>> your own hooks is specifying them in the hgrc file. (Or write a new extension.) +>> I guess use a very long command will work. +>> (e.g. ikiwiki --post-commit --a-lot-of-switches --set var=value $SRC $DEST) +>> (Fortunately ikiwiki supports --set var=value so without --setup works.) +>> +>> Alternative is always editing via cgi or pushing. Never work on the $SRC/repo directly. +>> --[[users/weakish]] + +>>> I don't see anything preventing you from using a setup file with +>>> `mercurial_wrapper => ".hg/ikiwiki-hook",` and then modifying the hgrc +>>> to run that wrapper. --[[Joey]] + +>> Thanks for pointing out this. I have some stupid misunderstanding on the +>> usage of mercurial_wrapper before. The wrapper works nicely! --[[weakish]] + +I add the following to .hg/hgrc:(I use changegroup since I don't think we need refresh per changeset, please point out if I am wrong.) + + [hooks] + changegroup = hg update >&2 && ikiwiki --setup path.to.setup.file --refresh + post-commit = path.to.the.mercurial.wrapper + +----- + +I have no idea when the deadlock will happen. --[[users/weakish]] + +> For the deadlock to occur, a edit has to be made via the web. +> +> Ikiwiki, +> running as a CGI, takes a lock on the wiki, and commits the edit, +> continuing to run in the background, with the lock still held. +> When the edit is committed, the hg hook runs, running `ikwiki --refresh`. +> Nearly the first thing that process does it try to lock the wiki.. +> which is already locked. This lock is taken in a blocking manner, +> thus the deadlock -- the cgi is waiting for the commit to finish before +> dropping the lock, and the commit is blocked waiting for the lock to be +> released. +> +> --post-commit avoids this problem by checking if the cgi is running +> and avoiding doing anything in that case. (While still handing the +> refresh if the commit was not made by the CGI.) +> So in that case, the commit finishes w/o ikiwiki doing anything, +> and the ikiwiki CGI handles the wiki refresh. +> --[[Joey]] + + *** I have a few notes on mercurial usage after trying it out for a while: @@ -50,3 +107,23 @@ I have a few notes on mercurial usage after trying it out for a while: --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]] + +>>>> Since this is confusing people, allow me to clarify: Ikiwiki's +>>>> recentchanges generation pulls log information directly out of the VCS as +>>>> needed. It caches it in recentchanges/* in the `scrdir`. These cache +>>>> files need not be preserved, should never be checked into VCS, and if +>>>> you want to you can configure your VCSignore file to ignore them, +>>>> just as you can configure it to ignore the `.ikiwiki` directory in the +>>>> `scrdir`. --[[Joey]]