Hg Init: Part 4. Correcting errors

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

One of the main advantages of Mercurial is that you can use personal repository clones to experiment and develop new features. If something went wrong, you can fix it in an instant.

Part 4. Correcting errors

')

Mercurial allows you to experiment freely. Imagine that while you were working, you did something wrong in the editor, and something terrible happened:





Emacs, how I love you. Anyway, everything can be fixed. The most common way to deal with such problems is to use the hg revert command:

hg revert
returns files to the state fixed in the repository.

This command will return the files to the exact state they had at the time of the last commit. Mercurial doesn’t like to delete anything, so instead of wiping the recipe in Latin , he renamed the file:



And what if everything has gone too far and you are already commited?



There is a hg rollback command that will save your skin, but only if you have not yet pushed (push) an erroneous commit into another repository. This command cancels one commit.

hg rollback
cancels one commit, provided that you do not push it into another repository.

Imagine you want to make a big experiment in your free time. Your boss hired a new designer, Jim. Since then, the designs that you receive have become simply absurd. They have an acidic green text, nothing is aligned (there are “artistic” reasons for this, yeah) and usability is lame. You want to come to work on the weekend and redo everything, but you are afraid to commit your changes, because you are not 100% sure that your ideas are better than that of this crazy designer. Jim smokes grass almost all the time from the moment he wakes up until he goes to bed. You do not want to use it against him, and everyone thinks that this habit does not concern anyone until the designs are in order. But there is a limit to everything. Right? And Jim's designs are not in order, and in general he is a brash one.

When working with Mercurial, you can simply create a clone of the entire repository:



It is not as wasteful as it may seem. Since the recipes and recipes-experiment repositories store the same thing (for now), Mercurial will use the “ hard links ”. So, a copy of the repository will be created quickly and does not take a lot of additional disk space.

Now you can make a number of changes in the experimental branch:



We begin my great experiment on the recipe for guacamole:



In the experimental repository, you can commit without fear:



You can safely make changes, fixing the result whenever you want. It gives you all the power of version control even for your crazy experiment, and no one gets hurt.

If you decide that the experiment failed, you can simply delete the entire directory with the experimental repository. No repository - no problem.

But if everything worked out, then you only need to push through your new edits:



And where are they pushed?

hg paths
displays a list of known remote repositories.

The line starting with “default” contains the path to the repository, in which hg push pushes the changes unless you explicitly specify another repository. Usually this line contains the path to the repository from which you made the clone. In this case, it is a local directory, but the URL can also be a path.



Don't forget that pushing changes into this repository ...



... does not cause changes to appear in the working directory.

hg parent
displays the change set in the working directory.

See you Edits about “Queso” in the fifth set of changes. But in my main repository, the work stopped at the fourth set of changes. From the fact that someone pushed changes to the repository , the working directory was not updated, and the fifth set of changes in it did not appear. So I'm still working on the fourth set of changes.



If I want to know that in the fifth set of changes, then I will need to use the hg update command:



See what happened? Changes were received, but they were after the version with which I worked. The push and pull commands simply forward changes between repositories. These commands do not affect what I'm working with at the moment.

Now the repositories look like this:



Mercurial is flexible when it comes to forwarding changes from repository to repository. You can push changes directly from the experimental to the central repository:



So the fifth changeset was sent from the pilot straight to the central repository. Now, if I return to my main repository, I’ll see that there’s nothing more to push through!



This is because Mercurial knows that in the central repository this (fifth) set of changes is already from somewhere. This is truly useful, because otherwise Mercurial might try to reapply the changes and become seriously confused.

Designer Jim, after being offered a job, promised to get down to business right away. However, he did not appear at work for another two months. Almost everyone has already forgotten about him and about the fact that they offered him a job, so when he was all so tanned first appeared in the office, honestly, no one could really understand who he was and what was going on at all. That was pretty funny. His appearance is typical. In the end, everything was sorted out, but since he was new, everyone was ashamed to ask him what the hell had happened. And about the scars and bruises on his face, too, did not ask. Never mind. We just hate this guy.

Sometimes it happens that after months, you find that you made a mistake.



Potato chips? What a..?!

Mercurial can remove the old changeset from the history. Mercurial looks at the change set, determines the reverse actions, and changes the current working directory. Let's try to remove that old revision number 2.



Mother of God, what was that?



Generally speaking, a lot of time could pass. Chips in general could disappear from the recipe. A lot of creepy things could happen. This means that sometimes after a revision is deleted, the changes cannot be merged. In such cases, you will get merge conflicts that you need to somehow resolve. We will talk about this in the next section.

check yourself

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

1. Roll back random changes. Before they are fixed in the repository, and after.
2. Locate the repository locally for experiments.
3. Push changes to different repositories.
4. Roll back the old error, which was long ago fixed in the repository.

Continued here:
Hg Init: Part 5. The merger process