Things I Learned From Writing a Mercurial Extension
I wrote my first mercurial extension today. It will print a log of all the commits you need to get from a changeset A which used to be the only head of a repository to a changeset B which is now the only head of the repository.It’s part of a project to get our buildbots hooked up to mercurial in a sane way. I need to make the same logic available via HTTP. It wasn’t too hard, but there are some tricky/undocumented things in the mercurial API that made life difficult.
- The wire protocol is a pretty elegant way to ask a server for changesets when you don’t know what the graph looks like yet with relatively few queries.
- The HTTP version of the protocol returns all the results in a plain-text format, except for the actual changesets which come across as a relatively opaque “bundle”.
- The
betweencommand in the wire protocol doesn’t do what you think it does, or what the documentation seems to say it does. Instead of returning all the changesets between point A and point B, it walks backward through the list returning a selection of changesets along the line. The farther you go back the less often it will pick a changeset to return. - There is currently no way to query hgweb for metadata about a particular commit, such as the author, date, or commit message. This is trivial to add, and I will be submitting a patch shortly.
- With a few extra functions, it should be relatively trivial to write a web repository browser which allows you to nagivate the revision graph graphically and dynamically load information about history as you need it.
cmdutil.show_changesetcan be used to show changesets the same way hg log does. I haven’t yet figured out how to expose all of the formatting options it accepts as options accepted by my extension.
March 6th, 2008 at 11:32 pm
Hi there,
Does this have to do anything with the fact that Mozilla is/was thinking to move to a dvcs. I found your post on the mozilla planet hence asked :)
March 7th, 2008 at 1:14 pm
Mozilla is actively using Mercurial already for mozilla2, though 1.9 development is still taking place in CVS.
April 11th, 2008 at 1:04 pm
Quoting wire protocol:
for tip, base in list:
walk back a linear branch, return elements 1, 2, 4, 8..
(and this lets us do bisection search if we diverge in the middle of one of these long branches)
Note the “1, 2, 4, 8”.
One of the biggest open problems is how to reduce the number of round trips the wire protocol does to O(1) while not increasing the transferred data outrageously. If we have a million changesets, we don’t want in/out/push/pull to have to transfer even a bit per changeset to figure out that we have all but 10 locally.