The workflow described by Brett looks like a patch-and-email one. It’s used by the Mercurial team itself, and has the advantage of not cluttering the history with lots of changes, since you only apply one patch in the end. However, in the not-so-long run I feel that a simpler and more mercurialic workflow would be a changesets-and-repos one. 1. Contributor clones the repo. 2. Contributor makes changes, committing as needed. 3. Contributor pushes to some public location and asks for pulling. 4. Core dev reviews and pulls from that repo into the official one. (optional step) Core dev may make additional edits (e.g. to NEWS and ACKS) in another changeset. One advantage of DVCS is that it separates the step of getting ideas from brain to code (commit) from the step of approving code and putting it into the official repo (pull). Having both the contributor and the core dev doing commits seems counter-natural to me. Advanced users may use MQ or pbranches or bookmarks to refine patches, but basic usage (commit and pull) still seems worthwhile to me.
And finally, http://hginit.com/ is one of the best Hg intros I have come across for explaining fundamentals. Agreed, although I’m not sure whether I’d call it a long introduction or a short tuto :) The “reeducation for Subversion users” page is helpful. hgtip.com has bite-sized tips for daily use, and http://hgbook.red-bean.com/ is an excellent read.
Regards