Hg Init: Part 6. Repository Architecture

This is the sixth, final part of the Hg Init Series : A Mercurial Study Guide by Joel Spolsky . Previous parts:

• "Retraining for Subversion Users"
• "The Basics of Mercurial"
• “We get used to working in a team”
• “Correcting mistakes”
• "The merger process"

Mercurial allows very flexible configuration of repositories. Plus, since merges work fine and you can rely on them, you can have specific service repositories in accordance with the requirements of the development process in your team.

Part 6. Repository Architecture

')
Our recipe is getting better:





Let's look closely at the change set number:



The first part of the number, 13, is short and comfortable. The problem is that ... you can not rely on it!

With the independent work of team members and the implementation of mergers, these short numbers can start to differ from different team members:



So in practice, I cannot say: “Well, let's release a version compiled from 13 sets of changes,” because employees may have different ideas about what is the 13th set. That is why there is also that crazy hex number.



This hexadecimal number is unique in all repositories and never changes.

So I can tell people: “Hey, today is the release! 1b03ab783b17th set of changes! ". Agree, it would be nice to be able to give this set a name ?

Well, you have this opportunity. This name is called a tag (or tag, from the English. Tag).



Let's take a look at the log now:



Note that adding a tag to a change set itself is a change set. This changeset is automatically recorded in the repository (committed). So now every time I want to refer to the version of the code that we released, I can use Version-1.0 instead of 1b03ab783b17 .

The deputy director descended from the 31st floor in order to participate in an office party for the release of a new version and brought a box of fairly expensive-looking sparkling wine. Stan got a little drunk. Well, not that little. Actually, it was something unheard of. Stan took off his shirt and, showing everyone his muscles and a solid belly, tried to impress the ladies from the marketing department. He boasted: “I will catch up on the lamps” (in our office we use long fluorescent lamps). In general, he jumped, grabbed the lamp and, of course, tore it along with the lamps and ceiling tiles. It is not surprising, because the lamp weighing about 4.5 kilograms hung on a pair of wires , and Stan's weight is just in the same popular range of 130-135 kilograms. Everywhere was broken glass and pieces of soundproof tiles. Stan fell right on the tailbone and began to complain that he would sue the company for unsafe working conditions.

The rest are back to work to work on Guac 2.0.



Commit:



Needless to say, this recipe is still questionable. It was not tested, for example. And then the customer calls.

“It’s too salty!” The customer whines. And no, he does not want to wait for the release of version 2.0 with the correction of the error.

Fortunately, we have that tag. I can use hg up to go to any version in the repository.



Now I can fix this stupid problem with salt:



Then:



Mercurial reminds me that my actions created a new head. Now there are two heads in the repository: version 2.0, which I recently worked on, and the version that I just committed.



At the moment I can give the version with the latest changes to the client, mark it as 1.1, and continue to work with version 2.0.



But there is one problem ... fixes about salt are missing in version 2.0. How do i fix this?





Here you go. I have to do tag merging. This is a known bug in Mercurial. The problem is that tags in Mercurial are simply a file called .hgtags, for which version control is also being conducted. Therefore, from time to time you need to manually merge different versions of the .hgtags file. In such a situation, your actions are simple ... you should always save BOTH versions of each line in the file.



The above simple way to switch to the old, labeled version is good if you only need to make one small unplanned change in the released code. But the truth is that in most software projects such situations occur all the time, and Mercurial has a more reliable way to deal with them.

So I’ll cancel all changes made after 1.0, return the repository to the state it had at release 1.0, and then I can show you a fashionable reliable way to fix the bugs of existing clients and work on the new version in parallel.



The idea is that instead of working with one repository, we will create two repositories. One repository is called stable , and the second is dev .

The stable major version of the code sent to the clients is stored in the stable repository. Every time you urgently need to fix a bug, you do this in stable . In our example, all patches for version 1.0 will fall into stable .

The dev repository is where the next major version is being developed, that is, version 2.0.

As soon as version 1.0 was released, I clone stable to dev :



Now I have two identical repositories:



Since the story in both repositories is the same until the 14th set of changes inclusive, Mercurial will use the “ hard links ” instead of making two copies on the disk. Therefore, the hg clone operation is performed quickly and cheaply, which means you can do many, many repository clones without hesitation.

Now let's start working on guac in the dev repository:



And fix that salt problem in the stable repository:



I will mark this version and release it as 1.1:



Now, from time to time, we need to pull in the changes from stable to dev :



Here is what we just did:



And if you can understand what is drawn on this crazy picture, then with the understanding of Mercurial you will have no more problems. The bottom line is that only bug fixes get into the stable repository, and the dev repository stores new code and merges with bug fixes.

There are other uses for multiple repositories.

• You can set up team repositories where several people work together on some new functionality. When they finish and everything done will work correctly, you push the changes from the command repository to the main repository, and everyone will see these changes.
  
• You can set up a repository for testers. Instead of pushing changes to the main repository right away, you will push changes to the testers repository. The testers check the changes and when (and if) the changes are approved, you can push the changes from the testers repository to the main repository. With this approach, the main repository will always contain the tested code.
  
• Since each developer has his own repository, you can pull out experimental changes from a friend's repository for trial without affecting the work of the rest of the team.
  

In large, complex organizations, you can combine these techniques and customize chains of repositories that pull changes from one another. As soon as some functionality goes through the stages of testing and integration, it is pulled into the repositories along the chain until it finally finds itself in the main repository, which stores the code that customers receive:

check yourself

Here is what you should be able to do after reading this part:

1. Mark old versions and return to them.
2. Organize team work with two repositories (stable and dev).

Well, it so happened that we reached the end of the manual. I did n't even get close to describing all the features of Mercurial, but there are enough materials for in-depth study. There is a book that describes everything in extreme detail. And if you have any questions, then I invite you to the Kiln Knowledge Exchange site (it's like StackOverflow , only for Kiln, and questions about Mercurial are more than welcome on this site).

Comments from the translator:
If you, like me, are interested in seeing guacamole, here is a video that shows the process of cooking this dish.