The Usefulness Of Mercurial

I Think almost all readers know what Mercurial is a distributed version control system for source code and other (mainly text) files. Many use it and know basic commands, such as deleting, adding files, creating commits, and sending local changes to the other repository. However, Mercurial has a lot of not so well-known functions and commands, which are often quite useful and convenient. Some of them can be used immediately after installation by default, some need to be enabled in settings, but for others you may need to download additional extension.

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

the
    the
  • hg serve (hgweb) — built-in web server
  • the
  • extensions of pager, progress, and color
  • the
  • hg [c]record — select individual changes for commit
  • the
  • revsets and filesets — search for commits, files requests of any complexity
  • the
  • evolve hg — Changeset Evolution or "variable history"


logo


hg serve (hgweb)



The standard delivery of Mercurial includes a web server that allows you to quickly browse the repository with user-friendly interface in any browser — just being in the folder with the repository, run hg serve and go to localhost:8000 (the default port is 8000). So, you can view almost all the information that is available through the usual command line interface. With another computer on the network can use hg clone with the address of the running hgweb to clone.

Of course, it would be strange if the web server can be used for just that — and it's not. Hgweb can be configured to handled multiple repositories, for example from one folder and also put him in front of nginx or another server (options communications enough — through plain http port, for example, or wcgi). The details of the configuration considered in particular in the official wiki Mercurial. Important function, which is sometimes lacking in hgweb — user authorization and the right to read/write — can also be implemented when installing and configuring additional frontend servers. For example, I'm using a standard http-authorization in nginx, which prohibits any unauthorized access to private repositories, and push in public.

As for appearance, comes bundled with several themes to choose from, the default is to use "paper".

Examples: selenic.com/hg official repository hg.python.org — repository Python hg.aplavin.ru — my (mostly) the repository.

extensions of pager, progress, color



These extensions are included in the installation of Mercurial, and to use, simply enable it in the settings. For this you need to add to the file ~/.hgrc section of the extension:

the
[extensions]
pager = 
progress = 
color = 


(Yes, after the equals signs do not). These extensions make working with the CLI-based interface is somewhat more convenient: conclusions many teams become colored during long operations displays the progress bar, and long sheets of commands like hg log can be scrolled — they open in a standard pager'e (usually less). Unfortunately, the help pages (hg help) are opened as before, and for their easy viewing need to manually add | less. These extensions are not enabled by default, as the author says, Mercurial, because sometimes encountered unexpected problems, particularly on Windows.

hg [c]record



Often after a long edit source code it is easier to split the changes into several commits, and not to make a big one. The standard delivery of Mercurial for this is the extension of record, which is enough to turn on in settings to use. Then actually to select the changes you will need to run hg record and in a text interface to select the desired part.
However, this extension is not very convenient and is only suitable for occasional edits. If you use this feature often, it is better to download and connect other extension, not from the standard kit: crecord. It provides enough easy to use graphical interface (an example from the author: image). Of course, there are fully graphical utility to do this (for example, I liked qct written in Qt), but for simple edits right on the spot in the console crecord quite comfortable.

revsets



Mercurial uses a query language that can be used for arbitrarily complex search criteria, commits, and it is supported in all teams that work with the commit (and soon to be in the hgweb). For example, almost "classical" example — there is some commit which fixed a bug and need to find the releases in which this bug fix got. Assuming that the job releases, use tags (all the projects seen and do), such a request can be formulated as 'tag() and descendants(x)' or 'tag() and x::' (where x — the ID of the commit). That is, if you run hg log 'tag() and x::', we can see all the required releases. Detailed information about the syntax and all available functions — hg help revsets, or official website.

filesets



Filesets also provides a query language similar to revsets, but to specify the file (for corresponding commands that work with files). He used almost the same except you need to add set:, to avoid confusion with the usual file names. As for the supported functions, they are also the standard of assistance: hg help filesets.

Changeset Evolution



Extension evolve experimental, which is developing a (mostly) one of the team members Mercurial. It is experimental because it is still not completely solved the issues with the UI and performance in some cases and not due to lack of stability (generally speaking, of the code associated with its functions, is very Mercurial, but it does not work by default). In particular, this extension is used in the official repository of Mercurial.

Changeset Evolution when the connection is not only adding new teams but also changes the behavior of standard (and other extensions) — those are in any way edit history: commit --amend, rebase, histedit and some others. When you use the evolve no commits are not removed completely from the repository (except for the command strip, designed for complete removal, which may still be useful). Any edit history simply marks more unnecessary commits as deleted (or rather, the deprecated — obsolete), and the new commits, as replacing them. Thus, you can always find any version changes that previously existed.

Also, receive additional "buns" — the ability to edit changes already sent to the public repository. And those who has a local copy when loading the new changes will also receive information about the remote (legacy) and commits to their local repository will also change (provided, of course, they have also included this extension). Without the evolve to dostich impossible.

Opinion



Generally, in Mercurial there are other "advanced" features, but in this article I have tried to describe those of them that may be useful to many users, and which people do not use often due to ignorance. I would also like to add that in Mercurial a very strict policy of backward compatibility — the changes do not affect existing functionality and add new. A very old version on the server can work with a new client, and Vice versa (of course not supported in older version of the function will not work). This is a serious backward compatibility applies to all commands and functions visible to the user, that is, the internal API may change (but for no good reason it also did not do).
I personally use Mercurial at a basic level for several years, and this year participating in Google Summer of Code with project improve hgweb. Along the way, communicating with developers, learned and began to use in particular, as described in this article functions.
Article based on information from habrahabr.ru

Комментарии

Популярные сообщения из этого блога

Looking for books as you want

Automatically create Liquibase migrations for PostgreSQL

Vkontakte sync with address book for iPhone. How it was done