Mercurial: where to start implementation and why patches are needed

Published on March 22, 2012

Mercurial: where to start implementation and why patches are needed

Oddly enough, but among programmers there are still quite a few who do not see the point in version control systems (SLE) or simply do not know about them. There are also enough people who know, but are not aware of where to start the implementation of, or, when used, pass by very convenient features.

Once upon a time, having lost another archive with a new version of my program, I came across a surprised look from the customer and the question: “I mean, no? But we paid you for this work. ”At that moment, I myself did not hear anything about them, but since this was far from an isolated case in the organization, as a result, subversion was mastered . After some time, due to the nature of the work (frequent trips and the need to work with sources on business trips in different places), it was decided to switch to mercurial, which allows you to have a full copy of the repository, work with it as a full-fledged main repository (although this concept is conditional, it is assigned as the main one to avoid confusion) and did not have the limitations and problems that svn had at that time (the impossibility of which this is the moment to get the right working copy of the desired revision and dependence on the central repository). Mercurial on Linux proved to be easy to learn and easy to use.

After the development and implementation, it remained only to sympathize with the neighboring department, where chaos still reigns, despite the fact that we managed to instill SLE in it already. True, at the moment this is more dependent on people who just do not see the point in such systems.

I think it is worth saying also that hard currency allows you to debug programs faster due to the fact that you can always get the previous revision of the source, where there was no error and easily and quickly see what changes have occurred since that moment. Ideally, revisions should be small so that the search is faster.

How to start implementing mercurial?

When the developer is alone, this question does not arise. I downloaded, installed, figured it out, use it.

If the team is small, then, in the absence of understanding on the part of ordinary workers, it is done on a voluntary-compulsory basis by a decree from above or a long education from below. With an understanding, everything turns out by itself.

A large team combines everything described above. It is only worth remembering that with a large topic in which everyone participates, reluctance to use hard currency leads to an increase in development time and a possible loss of funds. Therefore, one even has to convince the customer that the source files transferred to him must be stored using version control, so that his weighty word influences overly strengthened minds.

You should start by highlighting the person (a small group) who will follow the main repository and make all the changes to it. The rest should only do this through this person / group. At the same time, the group of "custodians" should be competent enough to see a discrepancy with the ideas of the stored software and, of course, all changes to the code should be brought to a state in which they can be entered into the repository without overlays. Of course, people watching the repository should know SLE no worse than the rest, but at least - to fulfill their duties. They can also train others in case of misunderstanding.

To explain why this is necessary, I will give a couple of examples.

Once, having arrived on a business trip, I looked at the repository that was stored there (it was just considered the main one) and saw a wonderful revision with a description of special characters, hieroglyphs, and other obscene language. It turned out that these changes were made there by people who are not very versed in this and who did not care about such trifles as the incorrect encoding of the text. But at the same time, it became impossible to understand what the changes were there and who made them after that. There was no possibility to roll them back either (there is actually an opportunity, but it is time consuming and time consuming).

Also, more than once it was seen repositories killed to death, from which nothing could be obtained at all, because the user who made the changes messed up the commit structure. Why, and he himself sometimes spoiled while studying. True, mostly copies. Therefore, to protect the integrity of the data you need a knowledgeable person.

About how to use mercurial`om and I will not tell the team, because their site is full of documentation.

Why do we need patches in mercurial?

Patches are a very powerful and controversial mercurial feature.

Initially, hg had the ability to make changes only by commits (commit), which could not be fixed after being added to the repository, except for the last, it could be rolled back. But only one. Over time, the mq extension appeared, which allowed creating patches similar to a regular commit, but mutable. Those. A patch is a set of changes from the last commit / patch that can be fixed.

This is strength and weakness at the same time. The strength of this is that if you forgot something, sealed up, did not notice an error, then this can be fixed right in this change. Patch [and] can be sent via chat / icq / jabber / e-mail, etc., because Compared to the entire program, it is small. Here we can say that there is a so-called bundle, i.e. a piece of the repository between the two commits, but you can simply open the patch and see / evaluate it, then fix it, if necessary, but the bundle isn’t.

The weakness of the patches is that the more they are, the more likely it is to mess with their storage in the repository. Or, when correcting the oldest patch in the queue, you may need to edit all the others that this edit may affect.

From here we can conclude:

  • using patches improves the appearance of the repository, as allows you to squeeze a bunch of commits with corrections of your changes into one, due to the fact that the patch can be edited;
  • it’s convenient to forward the patch due to its small size, which can save money and time;
  • it is undesirable to make a patch large (as well as a commit), because this makes it difficult to find an error in it;
  • the patch can be easily opened and see the changes in it with any text editor / viewer;
  • there should not be many patches in the queue (preferably no more than 7-10, then it becomes inconvenient to work with them), after gaining critical mass and readiness they need to be transferred to commits (hg qfinish);
  • as with any commit, the software with the patch should at least compile and it is highly desirable to run (although this, of course, is optional, but will avoid unpleasant moments when trying to run the software of any revision);
  • with proper knowledge and care, the patch can be edited directly in the patch file, but it should not be superimposed on a working copy;
  • it is desirable to make commits and patches logically complete;
  • It’s a good idea in a patch / commit to make a one-line heading (no more than 70 characters), reflecting the whole essence of the changes and write an ample comment through an empty line explaining what and why was done in the patch. This will help to figure out, for example, in a year, what was done there for the developer or for those who will replace him, and it will also be convenient to watch shortened and full revision logs.

In the end, I want to add that mq is included in the mercurial package, as well as the hgk extension, which allows you to display a window where you can type the appropriate command (hg view), where you can see the revision tree and the changes that have been made in them, which is very convenient. Patches are marked there so that it is noticeable that these are not commits. All extensions must be written in the .hgrc configuration file.

That's all for now. Maybe someone will help.