I assume you mean with a darcs cgi? In
any case, hg serve is undeniably easier.

I simply meant any old “dumb” http server.
I used thttpd as an example because I know off the top of my head how to start new daemons as non-privileged users on non-privileged ports.

I was operating on the assumption that one starts an http server in order to export the repository to anonymous users. Obviously if you want something like ViewVC, you’d need to use a non-”dumb” httpd; hg serve falls into this category.

thttpd: http://www.acme.com/software/thttpd/

viewvc: http://www.viewvc.org

It’s worth pointing out that darcs’ repo-local boring file depends on which version of darcs did the darcs init' ordarcs get’, and that it doesn’t ever get updated by a push or pull. So if you make a repo with darcs 1.0.3, it will have “obsolete” or “wrong” boring entries. If you have a heterogeneous develop group, some using old versions, this may cause confusion if generated files are ignored by one version (by default) but not another.

ftp://twb.ath.cx/Preferences/.hgignore

I found this pretty annoying, since I often use temporary and feature branches, and these would clobber defaultrepo. In ~/.darcs/prefs I have ‘ALL no-set-default’, which amounts to adding –no-set-default to each invocation. AIUI this means _darcs/prefs/defaultrepo is only written if it does not already exist, which is the best DWIM heuristic I’ve seen so far (for me, anyway).

http://revctrl.org/ and irc://irc.freenode.net/#revctrl

darcs amend makes this very easy, whereas it is several steps in hg — or impossible, if you have committed another changeset (e.g. an unrelated typo fix in ./doc/) after your partial changeset.

You can accomplish the darcs amend workflow with MQ, but it has to be intentional. I too really like darcs amend.

I wish to emphasize the (current) lack of an analogue of “darcs amend” in Mercurial. In the same way I compulsively save a source file whenever I stop typing, I like to compulsively record incomplete patches in my local working repository and then incrementally re-record them until the patch is complete (whereupon I push it upstream).

You can easily do that via MQ, but it’s noticeably more involved:

• Create a new patch via hg qnew "commitmessage" patchname (add -f if you already have changes in your working directories)

• Refresh the patch with hg qrefresh, or just create new patches on top of the old one and merge everything later

• [OPTIONAL] If you used the second solution (create several patches), hg qgoto the initial patch, then hg qfold to fold all the patches into the original one

• Finally, hg qdel-r qbase:qtip will transform all your MQ patches into regular Mercurial revisions

The edge over darcs amend is that unless you specifically ask that they are, mq patches are not versioned, thus can’t be pulled by someone pulling from you.