Mercurial: where to start implementation and why patches are needed
Strangely enough, but among programmers there are still quite a lot of those who do not see the point in version control systems (SLE) or simply do not know about them. It is enough for those who know, but do not know where to start implementation or, when used, pass by very convenient features.
Once upon a time, having lost another archive with a new version of its program, I came across a surprised look at the customer and the question: “In the sense of no? But we paid you for this work. ”At that moment I didn’t hear anything about them, but since this was far from an isolated case in the organization, subversion was finally mastered. After some time, due to the nature of the work (frequent travels and the need to work with source codes on business trips in different places), it was decided to switch to mercurial , which allows you to have a complete copy of the repository, to work with it as a full-fledged main repository (although this the concept is conditional, it is mainly assigned to avoid confusion) and did not have the limitations and problems that svn had at that time (the impossibility at some point to get the correct working copy of the required revision and dependence on the central repository). Mercurial on Linux was easy to learn and easy to use.
After mastering and implementation, it remained only to sympathize with the neighboring department, where chaos still reigns, in spite of the fact that we were already able to inculcate hard currency there. However, at the moment it depends more on people who just do not see the point in such systems.
')
I think it should also be said that SCR allows you to debug programs faster due to the fact that you can always get the previous revision of the source code, where there was no error and quickly and easily see what changes have occurred since then. Ideally, revisions should be small so that the search is faster.
How to start the introduction of mercurial?
When a developer is one, this question does not arise. I downloaded, installed, figured out, use.
If the collective is small, then, in the absence of understanding on the part of ordinary workers, it is done on a voluntary-compulsory basis by decree from above or by long enlightenment from below. With understanding, everything turns out by itself.
In a large team combines all of the above. Only it is worth remembering that with a large topic in which everyone is involved, the reluctance to use SCR leads to an increase in development time and possible loss of funds. Therefore, it is even necessary to convince the customer that the source code to be transmitted to him should be stored using version control, so that his weighty word influenced minds that were too strong.
You should start with selecting a person (small group) who will monitor the main repository and make all 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 the discrepancy with the ideas of the stored software and, of course, all changes to the code should be brought to the state in which they can be entered into the repository without overlays. Of course, people who follow the repository should know the hard currency no worse than others, but at least in order 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 so on. It turned out that these changes were made there by people who didn’t understand much about it and were not worried about such trifles as incorrect encoding of the text. But at the same time, it was impossible to understand what was there for the changes and who made them after that. There was no possibility to roll them back either (the opportunity is in fact, but time consuming and effortless).
Also, not once have I seen repositories killed to death, from which nothing could be obtained at all, because The user who made the changes spoiled the commit structure. Yes, what really, and he sometimes spoiled while studying. True, mostly copies. Therefore, to protect the integrity of the data you need a knowledgeable person.
I will not tell you how to use mercurial and commands, because their website is full of documentation.
Why do we need patches in mercurial?
Patches are a very strong and ambiguous mercurial feature.
Initially, hg had the opportunity to make changes only by commit (commit), which could not be fixed after the repository was added, except for the last one, it could be rolled back. But only one. Over time, the mq extension appeared, which made it possible to create patches similar to a regular commit, but variable. 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, it was sealed up, did not notice the error, then this can be fixed right in this change. The patch [and] can be sent via chat / icq / jabber / e-mail, etc., because compared to the whole program, it is small. Here we can say that there is a so-called. bundle, i.e. a piece of the repository between two commits, but the patch can simply be opened and viewed / evaluated, then corrected, if necessary, but there is no bundle.
The weakness of the patches is that the larger they are, the more likely they are to mess up with storing them in the repository. Or, when fixing the oldest patch in the queue, you may need to edit all the others that this edit may affect.
From here we can draw conclusions:
In the end, I want to add that mq is included in the mercurial package, and also the hgk extension is included there, which allows you to display a window when typing the appropriate command (hg view), where you can see the revision tree and the changes that were made in them, which is very convenient. The patches are marked there so that it is noticeable that they are not commits. All extensions must be specified in the .hgrc configuration file.
That's all for now. Maybe someone will help.
Once upon a time, having lost another archive with a new version of its program, I came across a surprised look at the customer and the question: “In the sense of no? But we paid you for this work. ”At that moment I didn’t hear anything about them, but since this was far from an isolated case in the organization, subversion was finally mastered. After some time, due to the nature of the work (frequent travels and the need to work with source codes on business trips in different places), it was decided to switch to mercurial , which allows you to have a complete copy of the repository, to work with it as a full-fledged main repository (although this the concept is conditional, it is mainly assigned to avoid confusion) and did not have the limitations and problems that svn had at that time (the impossibility at some point to get the correct working copy of the required revision and dependence on the central repository). Mercurial on Linux was easy to learn and easy to use.
After mastering and implementation, it remained only to sympathize with the neighboring department, where chaos still reigns, in spite of the fact that we were already able to inculcate hard currency there. However, at the moment it depends more on people who just do not see the point in such systems.
')
I think it should also be said that SCR allows you to debug programs faster due to the fact that you can always get the previous revision of the source code, where there was no error and quickly and easily see what changes have occurred since then. Ideally, revisions should be small so that the search is faster.
How to start the introduction of mercurial?
When a developer is one, this question does not arise. I downloaded, installed, figured out, use.
If the collective is small, then, in the absence of understanding on the part of ordinary workers, it is done on a voluntary-compulsory basis by decree from above or by long enlightenment from below. With understanding, everything turns out by itself.
In a large team combines all of the above. Only it is worth remembering that with a large topic in which everyone is involved, the reluctance to use SCR leads to an increase in development time and possible loss of funds. Therefore, it is even necessary to convince the customer that the source code to be transmitted to him should be stored using version control, so that his weighty word influenced minds that were too strong.
You should start with selecting a person (small group) who will monitor the main repository and make all 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 the discrepancy with the ideas of the stored software and, of course, all changes to the code should be brought to the state in which they can be entered into the repository without overlays. Of course, people who follow the repository should know the hard currency no worse than others, but at least in order 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 so on. It turned out that these changes were made there by people who didn’t understand much about it and were not worried about such trifles as incorrect encoding of the text. But at the same time, it was impossible to understand what was there for the changes and who made them after that. There was no possibility to roll them back either (the opportunity is in fact, but time consuming and effortless).
Also, not once have I seen repositories killed to death, from which nothing could be obtained at all, because The user who made the changes spoiled the commit structure. Yes, what really, and he sometimes spoiled while studying. True, mostly copies. Therefore, to protect the integrity of the data you need a knowledgeable person.
I will not tell you how to use mercurial and commands, because their website is full of documentation.
Why do we need patches in mercurial?
Patches are a very strong and ambiguous mercurial feature.
Initially, hg had the opportunity to make changes only by commit (commit), which could not be fixed after the repository was added, except for the last one, it could be rolled back. But only one. Over time, the mq extension appeared, which made it possible to create patches similar to a regular commit, but variable. 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, it was sealed up, did not notice the error, then this can be fixed right in this change. The patch [and] can be sent via chat / icq / jabber / e-mail, etc., because compared to the whole program, it is small. Here we can say that there is a so-called. bundle, i.e. a piece of the repository between two commits, but the patch can simply be opened and viewed / evaluated, then corrected, if necessary, but there is no bundle.
The weakness of the patches is that the larger they are, the more likely they are to mess up with storing them in the repository. Or, when fixing the oldest patch in the queue, you may need to edit all the others that this edit may affect.
From here we can draw conclusions:
- using patches improves the repository view, because allows you to shrink a bunch of commits with fixing your changes to one, due to the fact that the patch can be edited;
- the patch is convenient to send because of its small size, which can save money and time;
- it is undesirable to make a patch large (like a commit), since 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 be compiled and highly desirable to run (although this is of course not necessary, but it will avoid unpleasant moments when trying to run the software of any revision);
- With proper knowledge and caution, the patch can be edited directly in the patch file, but it should not be applied to a working copy;
- it is desirable to make commits and patches logically complete;
- A good idea in a patch / commit is to make a single-line heading (no more than 70 characters), reflecting the whole essence of the changes, and after a blank line write a spreading commentary explaining what was done in the patch and why. This will help to figure out, for example, a year later, what was done there to the developer or to those who change it, and it will also be convenient to watch the abbreviated and full logs of revisions.
In the end, I want to add that mq is included in the mercurial package, and also the hgk extension is included there, which allows you to display a window when typing the appropriate command (hg view), where you can see the revision tree and the changes that were made in them, which is very convenient. The patches are marked there so that it is noticeable that they are not commits. All extensions must be specified in the .hgrc configuration file.
That's all for now. Maybe someone will help.
Source: https://habr.com/ru/post/140496/
All Articles