Release Engineering uses hg a lot. Every build or test involves code from at least one hg repository.
Last year we started using some internal mirrors at the same time as making use of the hg share extension across the board, both of these had a big impact on the load on hg and time to clone/update local working copies.
I think what we’ve done is pretty useful and resilient to various types of failure, so I hope this blog post is helpful for others trying to automate processes involving hg!
The primary tool we’re using for hg operations is called hgtool (available from our tools repo). Yes, we’re very inventive at naming things.
hgtool’s basic usage is to be given the location of a remote repository, a local directory, and usually a revision. Its job is to make sure that the local directory contains a clean working copy of the repository at the specified revision.
First of all, you don’t need to worry about doing an ‘hg clone’ if the directory doesn’t exist, or ‘hg pull’ if it does exist. This simplifies a lot of build logic!
Next, we’ve build support for mirrors into hgtool. You can pass one or more mirror repositories to the tool with ‘–mirror’, and it will attempt to pull/clone from the mirrors before trying to pull/clone from the primary repository. At Mozilla we have several internal hg mirrors that we use to reduce load on the primary public-facing hg servers.
To improve the case when you need to do a full clone, we’ve added support for importing an hg bundle to initialize the local repository rather than doing a full clone from the mirror or master repositories. You can pass one or more bundle urls with ‘–bundle’. hgtool will download and import the bundle, and then pull in new changesets from the mirrors and master repositories.
Finally, hgtool supports the ‘hg share’ extension. If you specify a base directory for shared repositories, all of the above operations will be run on a locally shared repository first, and then the working copy will be created with ‘hg share’, and updated to the correct revision.
There are all kinds of fallback behaviours specified, like if you fail to import a bundle, try to clone from a mirror; then if you fail to clone from a mirror, try to clone from the master. These fallbacks have resulted in a far more resilient build process.
