The .hgrc file
This holds the configuration settings for Mercurial, and lives on *nix systems in ~/.hgrc. Mine contains:
; editor used to enter commit logs, etc. Most text editors will work.
editor = vim
username = Lorna Mitchell
Bitbucket actually shows you the command to clone right on the project page, which I think is a nice touch. And it is literally this simple :) Clone creates the local repo and working directory for you, and you are ready to go.
Coming from a Subversion background, Mercurial’s status command feels like coming home. It simply shows what has been added, modified, removed, obstructed or whatever, using most of the same symbols as SVN does. It also adds changed files automatically which may or may not annoy you depending on how you work – I don’t mind that. Changes shown in status are changes not committed yet.
Like so many of the other version control systems, you can add a -m switch to hg commit to put your message in on the command line if you wish:
hg commit -m "eliminating single-character variable names from the views"
Simply add the paths (or patterns) to the files you want to add, and mercurial will add them and show them with an “A” next to them in hg status.
Delete files that are currently being tracked by mercurial – if you see an exclamation mark in your hg status list, that’s an obstruction and means you deleted a file without telling mercurial to do it for you. Fix this with hg revert:
This command puts the name file(s) back to how they were at the last commit. So if you have added, removed or changed a file, this will be undone by the revert command. Check status again afterwards to make sure things look as you expect.
Shows content differences since the last commit. Bear in mind that it does not show property differences so changes in hg status may not result in the files showing in hg diff. You can also diff between revisions and repositories as you wish.
Shows the change history for this repository. Mercurial uses both numeric and hash identifiers for its revisions, and automatically tags the most recent local revision with the name “tip”.
Pulls in changes from another repository – if you don’t specify otherwise this will be the respository you originally cloned, but since this is a distributed system, you can actually pull changes in from anywhere.
Pushes your changes back to the repo you cloned. Remember that you’ll need the relevant security in place to do this, although it is possible to save passwords and other settings in ~/.hgrc
Now for a few bonus tips, maybe not commands you use every day but ones I really really like!
hg archive [path]
The archive command does the equivalent of svn export, but for mercurial. Simply specify a path and mercurial takes a snapshot of your local repo and places it there with no version control information in it. Useful for deployment tasks.
hg outgoing and hg incoming
I’ve been pretty excited since falling over these commands – they tell you which changes are in your local repo ready to be pushed, and which are in the remote repo ready to be pulled in – basically a simple diff between the locations. I really like this feature! (If anyone knows how to do this in git, I’d be grateful!)
That was a quick starter-for-ten on the mercurial usage front, I think this is a great tool as it has all the features of a distributed system but is simple and easy to use, especially for those coming from Subversion. There is a great mercurial tutorial from Joel Spolsky and the Selenic FAQs are also excellent.
If you have additional tips or want to share your mercurial experiences, add a comment!