Hg Init: Part 3. We get used to working in a team

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

• "Retraining for Subversion Users"
• "The Basics of Mercurial"

One of the advantages of using Mercurial is the ability to work as a team on one code. Mercurial allows everyone to work independently and helps to merge their changes.

Part 3. Getting used to working in a team

')

When teaming with Mercurial, it is common to set up a central repository in addition to the personal repositories located on the computers of team members. The central repository can be considered as a kind of flea market, that is, as a place where they meet and exchange what has been done.





The easiest way is to create a central repository using the built-in Mercurial web server. You just need to create a repository with hg init and open it with hg serve . By default, the repository will be available on port 8000.

hg serve
starts the web server and makes the current repository available on the Internet.

Since the server is running on joel.example.com , I can simply open joel.example.com:8000 in the browser and see that the server is running, though the repository is completely empty.



Having a running central web server, I can clone the central repository from the server to my computer for personal use. The repository is currently empty, so I will get another empty repository as a result of cloning.

hg clone
makes a complete copy of the entire repository.

Now I will create a guac file in which I will write down my famous recipe for guacamole .



I will add and save this file to the repository. This will be the first official version:



I will write a comment to the commit:



I will quickly edit the file, making one small change, so that we have at least a little history of changes in the repository.



And fix the changes:



Notice that when I commit this time, I used the argument -m , which I hadn’t done before. This is simply to specify a comment on the commit in the command line and not to use the editor.

Well, what do we have? I currently have a central repository and my personal clone of this repository. I made two changes and fixed them, but these changes are stored in my clone. They are not in the central repository yet. So it looks like this:



And now I will use the hg push command, which will push my changes from local to central repository:

hg push
pushes recent changes from the current repository to the central one.

Well, great. It is clear that this will not work. I don’t want to think about the security and consequences of launching a web server with the permission of everyone to push its stupid changes into it. Suffer a little, I'm going to set up the server so that he is allowed to do anything. You need to edit the .hg \ hgrc file on the server:



Needless to say, it is not safe. But if you are in a secure LAN at work, and you have a good firewall, and you trust everyone in your network, then this can be done. Otherwise, you should read about the security settings.

Well, it's time to restart the server:



Now I should be able to push through the changes:



Aha Now everything looks like this:



I know what you're thinking. You think: “Lord, Joel, this is all strange. Why in the repositories are changes , not files ? Where is that guac file ? ”.

Well, yes, strange. But this is how distributed version control works. Repositories simply store large stacks of changes. Imagine that one change is like a sheet of partially transparent material. If you have a pack of such sheets, and you stack them on top of each other so that the latest change is on top, and then look at this pack from top to bottom, then - yes, yes, yes, ladies! - see the current version of the file. If you remove sheets one by one from the top of the stack, you will see more and earlier versions of the file.

We use the browser and again look into the central repository:



There is exactly what was expected.

Now I’ll call Rosa to help me with my recipe. Rosa from the testers team. Anyone will confirm that it resembles one of those grannies that can be seen in Vegas, sitting for hours with a hanging jaw in front of a “one-armed gangster” and throwing coin after coin into a coveted crack. All the difference is that the Rose program is testing. You can give her a new version of the program, and she will check it on 23 Linux distributions. Will check in turn on each. Showing no emotion, without making unnecessary movements. Stopping only to inform you that a dot over i has been missed in the Turkish version of Ubuntu Linux. The rose tests well, but I swear it sometimes behaves like a zombie.



Rosa used the hg clone command to create her own complete repository copy. hg clone takes two arguments: the repository URL and the name of the directory you want to clone to. Rosa has her own recipes catalog.



Note that when hg log executed, it sees the whole story. That is, Rosa downloaded the entire repository with the complete history of everything that has already happened.

Now Rose will make a change and make it to the repository:



Here, commit. Please note that it can work even if the server is not working: the commit is fully executed on its machine.



While Rosa was making her changes, I also did something.



After I register my changes, it will be seen that in my log at number two the same is not indicated for Rosa.



The stories in our repositories began to differ.



Do not worry, we will soon see how to bring all these changes together to get excellent sweets with chips and peppers habanero .

Rose can continue to work without connecting to the server, making as many changes as you like. It can commit or roll back changes in its repository. However, the moment will come when she decides to share her changes with the others. She can run the hg outgoing command and see a list of changes waiting to be sent to the central repository. These are the changes that will be sent when hg push executed.

hg outgoing
displays a list of pending changes in the current repository.

hg outgoing is just a list of all such changes in the current repository that are not in the central repository.

Well, here Rosa pushes her changes into the central repository.



And now it looks like this:



After I went to drink the fourth cup of latte for today, I am also ready to push through my change about potato chips.



AAAAA !!! Mistake! Oh, by the way, see the message? Which one is written in, use the -f switch to force push (use push -f to force)? This is terrible advice. Never use the -f option for anything. You will regret using it. Just trust me at the moment.

The reason why Rosa managed to push through the changes, but I don’t have to say that potato chips and guacamole do not mix well. Just kidding! Just wanted to make sure that you haven't fallen asleep there yet.

The team ended up with an error because each of us made changes, which means they need to be merged together, and Mercurial knows this.

First of all, I will take away all the changes from the central repository, which I don’t have yet to merge.



There's some gibberish about +1 head (+1 heads). This is because my repository, in which three changes had previously been carefully arranged, became a two-headed monster. At the top of the repository, two different changes are located dangerously. Here's what it looks like:



I now have both versions in the repository. Here is my:



And here is the Rose version:



And I have to merge these versions together. Fortunately, it's simple:



Look! The hg merge team took and merged both my “heads” (changes at the top of the repository) into one. Since in this case Rosa and I changed different parts of the file, there were no conflicts during the merge and everything went without a hitch.

hg merge
merges (merges) two "heads".

I still have to commit. It is important. If the merger failed, then I could always roll back and try again. But, since the merger was successful, I will commit. After that, I can push my changes into the central repository.



Now in the central repository is the same as in my:



Well, I have the changes Roses and my own changes, but Rosa does not yet have my changes.

There is one more thing related to Rosa, which I forgot to tell you. She is a doctor. Yeah, doctor, who is a doctor. Well, not wonderful? She was the head pediatrician at Mt. Sinai and received, probably, "five times more than this nasty pork pays its testers." No one knows for sure why she left medicine. The rest of the testers think something tragic has happened. She also had a family: on her desk a picture of a lovely ten-year-old child. But now she lives alone, and we do not want to climb into her soul.

Rosa needs to pull (pull) fresh incoming changes from the repository to get my changes.



Is done. Now, - it may seem strange to you, - despite the fact that Rosa has drawn new changes into her repository, these changes are not in her working directory .



See, She still works with corn chips . With corn chips!

She has my recent changes somewhere in the repository ...



Just my changes are not in her working directory. This is because it still changes the second set of changes. This can be seen by running the hg parent command:

hg parent
displays the change set in the working directory.

Mercurial is kind to us. Pulling changes is always safe. All that happens is getting fresh changes made by other people. We can start working with these changes later when it’s convenient for us.

Remember that the hg up command with no arguments will result in a working directory to the “tip”, that is, it will apply all changes to the topmost set of changes. In this case, this is the fourth set of changes:



Now Rosa sees the latest version with changes from both of us.

When you work in a team, the workflow will look much like this:

1. Pick up the latest version that everyone works with if you haven’t done this for a long time by doing:
   
   • hg pull
   • hg up
   
   
2. Make changes
3. Commit changes (locally)
4. Repeat paragraphs 2-3 until you get a good code that you want to dump on all the others.
5. When you are ready to share, execute:
   
   • hg pull to get someone else's changes (if any)
   • hg merge to merge these changes with your
   • testing! in order to make sure that nothing happened during the merger
   • hg commit (to commit the result of the merge)
   • hg push
   
   

check yourself

Here is all that you should be able to do at the moment:

1. Set up a central repository and give team members the opportunity to make clones of it.
2. Push changes to the central repository
3. Pull changes from the central repository
4. To merge changes from different authors

Continued here:
Hg Init: Part 4. Correcting errors