Mercurial Utility

I think almost everyone who reads knows what Mercurial is - a distributed version control system for source code and other (mostly text) files. Many use it, and know the basic commands, such as deleting / adding files, creating a commit and sending local changes to other repositories. However, Mercurial has many not-so-known functions and commands that are often quite useful and convenient. Some of them can be used immediately after installation by default, some need to be enabled in the settings, and for others you may need to download an additional extension.

A short list of what will be discussed in the article:

• hg serve (hgweb) - embedded web server
• pager, progress and color extensions
• hg [c] record - select individual changes for commit
• revsets and filesets - search for commits and files with queries of any complexity
• hg evolve - Changeset Evolution or "changeable history"

')

hg serve (hgweb)

Mercurial comes standard with a web server that allows you to quickly view the repository with a convenient interface in any browser - all you have to do is to hg serve while in the repository folder and go to localhost:8000 (standard port is 8000). So you can view almost all the information that is available through the usual command line interface. In this case, from another computer on the network, you can use hg clone with the address of the running hgweb for cloning.

Of course, it would be strange if the web server could only be used for this - and this is not so. Hgweb can be configured to process several repositories at once, for example from one folder, and also put nginx or another server in front of it (there are enough communication options - usual http through the port, or for example wcgi). Configuration subtleties are discussed in particular in the official Mercurial wiki. An important feature that is sometimes lacking in hgweb — user authorization and read / write permissions — can also be implemented by installing and configuring an additional frontend server. For example, I use the usual http authorization in nginx for this, which prohibits any unauthorized access to private repositories, as well as push to public.

As for the appearance, the set comes with several themes to choose from, the default is “paper”.

Examples: selenic.com/hg - official repository, hg.python.org - Python repositories, hg.aplavin.ru - my (mostly) repositories.

Pager, progress, color extensions

These extensions are included in the Mercurial installation, and to use it, simply enable them in the settings. To do this, add an ~/.hgrc section to the ~/.hgrc file:

 [extensions] pager = progress = color = 

(yes, after the signs of equality there is nothing). These extensions make working with the CLI interface somewhat more convenient: the output of many commands becomes colored, during long operations a progress bar is displayed, and long sheets of commands like hg log can be scrolled - they open in a standard pager (usually less ). Unfortunately, the help pages ( hg help ) open as before, and for their easy viewing you need to manually add | less | less . These extensions are not enabled by default, as the author of Mercurial says, because of occasional unexpected problems with them, in particular on Windows.

hg [c] record

Often, after long editing the source, it is more convenient to break the changes into several commits, rather than making one big one. In the standard Mercurial package, there is a record extension for this, which you simply enable in the settings for use. After that, in order to select the changes, you will need to execute hg record and select the necessary parts in the text interface.

However, this extension is not very convenient and is only suitable for episodic edits. If you use this function more often, it is better to download and connect another extension, not from the standard kit: crecord . It provides a pseudographic interface that is quite convenient for use (an example from its author: ). Of course, there are also completely graphical utilities for this (I, for example, liked qct written in Qt), but for simple edits right “on the spot” in the console, the crecord is quite convenient.

revsets

Mercurial uses a query language that can be used for arbitrarily complex search criteria for commits, and it is supported in all commands that work with commits (and soon will be in hgweb). For example, an almost “classic” example - there is a certain commit in which the bug is fixed, and you need to find releases to which this bugfix got. Assuming that tags are used to set releases (all projects that have seen and are doing so), such a request can be formulated as 'tag() and descendants(x)' or 'tag() and x::' (where x is the identifier commit). That is, if you execute hg log 'tag() and x::' , we will see all the required releases. Detailed information about the syntax and all available functions - hg help revsets or on the official site .

filesets

Filesets is also a query language, similar to revsets, but for specifying files (for the corresponding commands that work with files). It is used almost in the same way, only at the beginning you need to add set: so that there is no confusion with the usual file names. As for the supported functions, they are also in the standard help: hg help filesets .

Changeset evolution

The evolve extension is an experimental one that is currently being developed (mostly) by a member of the Mercurial team. It is experimental because of the still not completely resolved issues with UI and performance in some cases, and not because of lack of stability (generally speaking, part of the code related to its functions is in Mercurial itself, but does not work by default) . In particular, this extension is used in the most official Mercurial repository.

Changeset Evolution when connecting not only adds new commands, but also changes the behavior of the standard (and from other extensions) - those that somehow edit the history: commit --amend, rebase, histedit and some others. When using evolve no commits are completely removed from the repository (with the exception of the strip command, which is intended just for a complete removal, which can still be useful). Any history editing simply marks more unnecessary commits as deleted (more precisely, obsolete - obsolete ), and new commits - as replacing them. Thus, you can always find any version of the change that once existed.

Also, from additional received “buns” - the ability to edit changes already sent to the public repository. Moreover, those who have a local copy of it when downloading new changes will also receive information about remote (obsolete) commits and their local repositories will also change (provided, of course, that they also have this extension included). Without evolve this can not be reached.

Conclusion

In general, there are other “advanced” features in Mercurial, but in this article I tried to describe those that can be useful to many users, and which people do not use often because of ignorance. I would also like to add that Mercurial has a very strict backward compatibility policy - all changes made do not affect the existing functionality, but add a new one. A very old version on the server can work with a new client, and vice versa (of course, functions that are not supported in the old version will not work). Such serious backward compatibility applies to all commands and functions visible to the user, that is, the internal API can change (but without good reason this also does not do).

I myself have been using Mercurial at a basic level for several years now, and this year I have been participating in Google Summer of Code with the hgweb improvement hgweb . Along the way, communicating with the developers, I learned and began using the functions described in this article in particular.