Hg Init: Part 5. The Merge Process

This is the fifth part of a series Hg Init: Tutorial Mercurial by Joel Spolsky ( by Joel Spolsky ). Previous Parts:

• Retraining for Subversion Users
• The Basics of Mercurial
• “Get used to working in a team”
• “Correcting Errors”

Sometimes mergers have conflicts. They are usually easy to resolve. In any case, they must be resolved, or you will have several goals. And who needs it?

Part 5. The merger process

Ensuring the coordinated work of several people on the same code is an important function of the version control system.

Imagine that both Rose and I want to make changes to the guacamole recipe. Rose is working on quality avocados. Before starting, she updates her working directory, pulling fresh changes from the central repository.





Now a small edit:



It commits the changes and pushes them to the central repository:



At the same time, I make a change in another part of the file:



I can commit, but I can not push the changes to the central repository.



This is perhaps the least useful error message in Mercurial. It would be better this way:



So I will do:



Want to know what changes have just been received? There is a convenient way for this - the team. hg log -P .



Well, for sure, these are the changes that Rose made. And what's up with my repository now?



My repository has several goals. Essentially, my repository looks like this:



See two heads? They appeared because Rosa made her changes working with the seventh set of changes, and I also made my changes working with the same set. So now merge is required. [Editor prompts you not to use passive voice] I have to do a merge.



The merger team,, hg mergetook two heads and combined them. After that, she put the result in my working directory. She did not commit him. This gives me a chance to verify that the merge result is correct:



Sounds like the truth: Hass avocados and jalapeno peppers . So I will commit and push the changes to the server.



I push two sets of changes: my jalapeno changes and the result of the merge, which is also a set of changes.

Please note that there were no conflicts in our changes because Rosa and I worked on different parts of the recipe. Because the merger was super-duper simple. This is the most common situation, because in most organizations different programmers work on different parts of the code.

Sometimes there are strange organizations in which no one is ready to hit the table with his fist and still divide the areas of responsibility. This can provoke an unexpected and often inexplicable feeling of sadness among programmers. This situation is not easy to recognize. But there are symptoms: programmers close in toilets, programmers close in server rooms, high staff turnover, the sounds of stifled sobbing in the room, as well as unexpected damage to eardrums due to multiple shots of an assault rifle.

BUT, even in the finest organizations with the best leadership, merge conflicts sometimes happen, and Mercurial will require the merger to resolve the conflict. Let's see how this is done.

To begin with ... I want Rose to be aware of my changes about jalapenos:



Now we will see what happens when you have a real conflict: we both mess up a little with the ingredients.

I added a banana:



And the first I recorded the changes:



And God, God forgive me, added MANGO in the SAME PLACE of the recipe.



"Mature young" mango, I'm not joking.



This time I was the first to record the changes, so now Rose will have to deal with the merger. Haha



And suddenly, a conflict is revealed and a window of some program pops up to resolve conflicts with such a terrible interface that only the mother of this program can like it. But a program usually does pretty well what it is intended for, you just need to figure out how it works. The most common conflict resolution program of our time is KDiff3, so Rose will see the following:



In KDiff3, you have four panels. The top left is the original file. The upper middle shows Rosa her version of the file. The upper right shows Rose my version. The bottom panel is an editor in which Rosa collects the resulting file as conflicts resolve.

Resolving conflicts is simple enough. You need to go through all the conflicts and choose how to resolve each of them. Rosa went crazy and decided that the banana mango guacamole is not so bad:



By the way, I told you that Rosa seems to be meeting someone? Once she was seen leaving work with a guy who looked like Dennis Franz . In such a good mood as then she had not been seen for a long time.

Rose saves the changes and closes KDiff3.



And the conflict is resolved.

Here's what you should remember: you don’t have to merge, adapting to someone’s schedule. You can performhg pull whenever and if you don’t want to resolve conflicts immediately, you can freely continue to work and happily commit until you find time to do the merger.

check yourself

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

1. Work with code together with other people.
2. Receive their changes.
3. Push your changes.
4. Resolve conflicts that happen from time to time.
5. Diagnose some types of programmer melancholy.

The final part is here:
Hg Init: Part 6. Repository Architecture