I attended a semi-annual Mercurial developers meeting on Oct 7-9. While a
lot was discussed (full notes available at https://www.mercurial-scm.org/
wiki/4.0sprint), there were a number of developments relevant to Mozilla.
* Facebook has implemented an extension that effectively caches blame
lookups. My measurements show a 4-10x speedup across the board. Files that
used to take 10s to blame can now take under 1s! Bug 1308226 tracks rolling
it out to hg.mozilla.org
. It isn't likely to happen before December due to
a probable requirement on Mercurial 4.0.
* There was a demo of limiting blame output to certain lines. This is
useful for e.g. following the history of just a function. There was talk of
integrating this into the HTML interface (so you e.g. highlight lines and
then limit output to just those lines over time).
* Facebook demoed `hg absorb` which is probably the coolest workflow
enhancement I've seen to version control in years. Essentially, when your
working directory has uncommitted changes on top of draft changesets, you
can run `hg absorb` and the uncommitted modifications are automagically
folded ("absorbed") into the appropriate draft ancestor changesets. This is
essentially doing `hg histedit` + "roll" actions without having to make a
commit or manually make history modification rules. The command essentially
looks at the lines that were modified, finds a changeset modifying those
lines, and amends that changeset to include your uncommitted changes. If
the changes can't be made without conflicts, they remain uncommitted. This
workflow is insanely useful for things like applying review feedback. You
just make file changes, run `hg absorb` and the mapping of changes to
commits sorts itself out. It is magical.
* Facebook, Google, and Unity all are experimenting with virtual
filesystems for Mercurial (e.g. FUSE filesystems). This allows them to
bypass having to write 100,000+ files at checkout time and makes subsequent
operations like `hg update` much faster since the filesystem doesn't need
to be touched as much. This has the potential to significantly speed up VCS
operations in Firefox automation.
* Facebook has developed a large file storage extension using the git-lfs
* Google demoed a working narrow clone (clone a subset of files). It is a
3rd party extension for now. But they are still intent on upstreaming once
it is stable enough.
* `hg version` now runs under Python 3. It looks like official support for
Python 3 support will happen sometime in 2017.
* Facebook reported significant improvements to developer sentiment towards
Mercurial at Facebook. Initially, a lot of developers were skeptical about
Mercurial and preferred Git. Now, apparently a number of their developers
have forgot how to use Git. A number of their developers working on open
source projects on GitHub (which are essentially mirrors of subdirectories
from their monorepo) now prefer working out of a Mercurial clone instead.
Keep in mind Facebook essentially runs their own Mercurial distribution
that has a lot of customizations to work around rough edges. So the
Mercurial experience at Facebook is vastly different from the experience
* There are very promising performance wins when running Mercurial under
PyPy, especially on the server side.
* Facebook will be investing a lot of time in the next year into improving
the long tail of minor performance issues in Mercurial. They want all
commands to be as fast as possible.
* Facebook is writing a Mercurial server in Rust. It will be distributed
and will support pluggable key-value stores for storage (meaning that we
could move hg.mozilla.org
to be backed by Amazon S3 or some such). The
primary author also has aspirations for supporting the Git wire protocol on
the server and enabling sub-directories to be `git clone`d independently of
a large repo. This means you could use Mercurial to back your monorepo
while still providing the illusion of multiple "sub-repos" to Mercurial or
Git clients. The author is also interested in things like GraphQL to query
repo data. Facebook engineers are crazy... in a good way.
* Mercurial 4.1 should contain an `hg display <view>` command that provides
a common command for showing common views of various pieces of data. Look
for new views like `hg display inprogress` as an officially supported
version of `hg wip`.
* There were discussions on improving the robustness of clone (resume from
interrupted clone, automatic retries, etc).
* Supporting zstandard (an new compression format that beats zlib in
compression ratio and speed) in the core Mercurial distribution has a green
light. Look for initial support in Mercurial 4.1. This has potential to
drastically speed up several operations and to make servers scale much
* Work on a rewrite of the Mercurial book is underway. More info at
* Discussions about SHA-1 concerns, commit integrity/signing.
If you have any questions, just ask.