122 lines
6.3 KiB
Markdown
122 lines
6.3 KiB
Markdown
* 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 <address@domain>" 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.
|
|
* `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
|
|
|
|
[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]]
|
|
|
|
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:
|
|
|
|
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]]
|