Hg Init: Part 5. The merger process

This is the fifth 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”

Sometimes there are conflicts with mergers. Usually they are easy to resolve. In any case, they must be resolved, or you will have several "heads." And who needs it?

Part 5. The merger process

')

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

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





Now a small edit:



It captures the changes and pushes them into the central repository:



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



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



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



So I will do:



Want to know what kind of changes have just been received? For this there is a convenient way - the hg log -P . command hg log -P .



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



My repository has several heads. In fact, my repository looks like this:



See two heads? They came about because Rose made her changes by working with the seventh set of changes, and I also made my changes by working with the same set. So now merge is required. [The editor suggests that you cannot use the passive voice] I have to do a merge.



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



It seems to be true: Hass avocados and jalapeno peppers . So I will commit and push changes to the server.



I push two sets of changes: my changes about jalapenos and the result of a merger, which is also a set of changes.

Please note that there were no conflicts in our changes, because Rose 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 are working 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 are closed in the toilets, programmers are closed in the server, high staff turnover, sounds of choked sobs in the room, as well as unexpected damage to the eardrums due to repeated shots of an assault rifle.

BUT, even in the best 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.

For starters ... I want Rose to be aware of my changes about jalapenos:



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

I added a banana:



And the first recorded changes:



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



"Ripe young" mango, I'm not kidding.



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



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



In the KDiff3 program, you have four panels. The top left is the original file. The upper middle shows Rosa her version of the file. Top right shows Rosa my version. The bottom panel is the editor in which Rosa collects the final file as conflicts are resolved.

Conflict resolution is easy. 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, did I tell you that Rosa seems to be dating someone? Once she was seen leaving a job with a guy who looked something like Dennis Franz . In such a beautiful mood as they didn’t see her for a long time.

Rose saves the changes and closes KDiff3.



And the conflict is resolved.

Here is what you should remember: you are not obliged to merge, adapting to someone else's schedule. You can do hg pull anytime, and if you don’t want to resolve conflicts right away, you can continue to work freely and happily commit until you find the time to merge.

check yourself

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

1. Work with code together with other people.
2. Get their changes.
3. Push your changes.
4. Resolve conflicts that occasionally occur.
5. To diagnose some types of programmer melancholia.

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