]> sipb.mit.edu Git - ikiwiki.git/blobdiff - doc/todo/mercurial.mdwn
(tiny) markdown syntax
[ikiwiki.git] / doc / todo / mercurial.mdwn
index 5594a093c416a64248d0e4d4bf5fb59d83306c3a..26888131ee225ab9d9b344e0c671a153e6d385fa 100644 (file)
@@ -1,3 +1,80 @@
-* 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.
 * 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.
+
+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.
+
+I add the following to .hg/hgrc:
+
+    [hooks]
+    changegroup = hg update >&2 && ikiwiki --setup path.to.setup.file --refresh
+    post-commit = ikiwiki --setup path.to.setup.file --refresh
+
+I tried the follwing commands in $SRC:
+
+    touch deadlocktest.mdwn
+    hg add
+    hg ci
+
+No deadlock happens.  (Also I push to the $SRC from another machine, again, no deadlock.)  
+
+Of course these tests are too simple.  The problem is I have no idea when the deadlock will happen. If someone is kind enough to point out, I will run more test.
+
+
+***
+
+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]]