Hg Init: Part 1. Re-training for Subversion users

Hg Init: A Mercurial Tutorial.

Mercurial is a modern, open source distributed version control system. This system is a tempting replacement for earlier systems like Subversion. In this simple six-part tutorial, Joel Spolsky talks about the key principles of Mercurial.

If you used Subversion, then Mercurial will be incomprehensible. This part describes the main differences when working with Mercurial. If you have never used Subversion, you can simply skip this part .
')

Part 1. Re-training for Subversion users

What a confusion I had when programmers at my company decided to change Subversion to Mercurial!

To begin with, I began to give all sorts of stupid reasons for which we do not need to change anything. “We have to store the repository on a central server, it's safer,” I said. You know what? I was wrong. When working with Mercurial, every developer has a full copy of the repository on their hard disk. It is, in fact, safer . In any case, in almost every team using Mercurial, a central repository also exists. And you can back up this repository with all the obsession you need. And you can also arrange a three-step defense with Cylons , Attackers and pretty Labradudles or whatever your IT department requires.



“The problem with distributed version control systems is that they make branching too easy (branch),” I said. "And branches always bring problems." It turns out that here I was wrong too. This wave went. Branches have problems when working with Subversion , because Subversion does not store enough information for the merge to work properly. In Mercurial, merging is painless and easy, and therefore branching is common and harmless.

Then I said, "Well, I will use this system, but do not expect me to be able to figure it out." And I asked Jacob to make a cheat sheet for me, which will be everything that I usually did in Subversion, with an indication of their counterparts in Mercurial.

I can show you this cheat sheet, but I will not, because for several months it prevented my brain from rebuilding.

It turns out that if you used Subversion, then your head is a bit ... Uh-uh, how can I put it more softly? You are injured in the head! No, it did not work. You need retraining. I walked so wounded for half a year and thought that Mercurial is more complicated than Subversion. But this is because I did not understand how the new system actually worked. As soon as I understood how it works, it turned out - oops! yes it is simple enough.

So I wrote this manual for you, in which I tried very hard not to explain everything in terms of Subversion, because there were enough of those already wounded in the head. They are already enough. Instead, for those who switch to Mercurial from Subversion, I wrote this part at the beginning of the manual, which will try to eliminate as much harm as possible so that you can learn Mercurial from scratch.

If you have never used Subversion, you can skip to the next article ( “Fundamentals of Mercurial” ) and don’t miss anything.

Ready? Well, let's start with a short survey.

Question one: Do you always write the perfect code the first time?

If you answered "Yes" to the first question, then you are a liar and a crook. Get a "banana" and come to retake.

New code is buggy. It takes time for him to start working decently. In the meantime, this code can damage the rest of the developers in the team.

And this is how Subversion works:

• When you enter a new code into the repository, everyone gets it.

Since all the new code you write contains bugs, you have a choice.

• You can contribute buggy code and drive people crazy, or
• You can keep the new code until it is completely debugged.

Subversion constantly puts you in front of this terrible choice. Or the repository is full of buggy code, because it contains a new code that has just been written, or a new code that has just been written is not added to the repository.

As Subversion users, we are so used to this dilemma that it’s hard to imagine a system where this dilemma does not exist.

A team using Subversion often adds nothing to the repository for days or weeks. In such teams, newbies are afraid to upload something to the repository due to fear of breaking the build, or annoying Mike, the lead developer, or for similar reasons. Mike once got so angry about the changes that broke the build that he broke into the intern, brushed everything off his desk and yelled: “This is your last day!”. This day was not the last, but the poor intern practically wet his pants.

All these fears and concerns mean that people write code week by week without taking advantage of the version control system , and then they are looking for someone experienced to add the code to the repository. And why the repository, if they can not use?

Here is a simple illustration of life with Subversion:


When working with Mercurial , each developer has his own repository that lives on their computer:


So you can make changes to your repository and enjoy all the benefits of a version control system whenever you want. Each time, slightly improving the code, you can add it to the repository.

When the code is reliable, and you want to let others use it, you push through your changes from your repository to the central repository. Everyone pulls out general changes from the central repository and sooner or later everyone will receive your new code. When he is ready.

Mercurial shares the moment the code is entered into the repository and the moment this code is received by all the others.

And that means you can commit ( hg com ), but everyone else will not receive your changes. When you accumulate changes that suit you, which are stable and everything is cool, you push ( hg push ) them into the main repository.

Another big conceptual difference

Do you know that every street has a name?

Well, it turns out that in Japan it is not so. The Japanese usually just number the neighborhoods between the streets, and only very, very important streets have names.

Subversion and Mercurial have a similar difference.

Subversion thinks by revisions . A revision is what the entire file system looks like at a certain point in time.

In Mercurial, you think in changesets . A change set is a clear list of changes between two adjacent revisions.

Six or half a dozen of this - what's the difference?

That is the difference. Imagine that you and I are working together on some kind of code. And we made branches of this code, and each went to its place and made many, many independent changes in the code, so the branches went off quite strongly in different directions.

When we need to do a merge, Subversion looks at both revisions — my modified code and your changed code — and tries to guess how to blind them together in one big scary mess. Subversion usually fails to do this, and it turns out long lists of conflicts ("merge conflicts"), which are not really conflicts, but just places where the system could not figure out our changes.

For comparison, if we independently worked in Mercurial, then the system kept a series of changes . So when we want to merge the code, Mercurial actually has a lot more information: the system knows what each of us has changed , and can reapply these changes instead of looking at the final version and trying to guess how to put it all together. together.

If, for example, I changed a function a little and moved it somewhere, then Subversion really doesn’t remember it. So when it comes to merging, it can simply decide that a new function has appeared in the code from nowhere. At the same time, Mercurial will remember: the function has changed, the function has moved. This means that if you also changed this feature, then the likelihood that Mercurial will successfully merge our changes is much more.

Since Mercurial thinks in terms of changesets, you can do interesting things with these changesets. You can give these changes to a friend instead of making these changes to the central repository and forcing everyone to use them.

If all this seems a bit confusing to you - don't worry. As you read this manual, everything will have a clear meaning. At the moment, the most important thing you need to know is that because Mercurial operates on changesets rather than revisions, merging the code in Mercurial works much better than in Subversion .

And that means you can branch freely , because merging will not be a nightmare.

Want to know something funny? Almost every team that uses Subversion, with members of which I spoke, has a version of the same story. The story is so common that I just call it the “Main story about Subversion”. Here is the story: at some point they tried to make a branch in the development of the code. Usually in order for the version that was given by the customers to be separated from the version that the developers are busy with. And everyone told me that when they tried to do this, everything was fine until the moment when they needed to make a merger . And the merger was a nightmare. What was supposed to be a five-minute process turned into six programmers around a single computer that worked for two weeks, trying to manually add each bugfix from a stable branch to the developers branch.

And in almost every team they told me that they swore “never again” and abandoned the branches. And now they do this: every new feature in a large #ifdef block. So they can always work in the trunk of the repository, and clients never get a new code until it is debugged, and, frankly, this is ridiculous.

Separating stable and developed code is exactly what the version control system should allow you to do .

With the transition to Mercurial, you may not even realize this, but branching will again be possible and you will not need to fear anything.

This means that you may have team repositories, where a small team of programmers is working on a new feature, and, when everything is ready, merges their changes into the main repository. And it works !

This means that you may have repositories for the testing service, where a team of testers tries a new code. If it works, then the testing service makes changes to the central repository, which, in turn, means that there is always a reliable tested code in the central repository. And it works !

This means that you can conduct experiments in separate repositories, and, if the experiments are successful, merge the changes into the main repository, and if unsuccessful, then just throw them away. And it works !

And the last big conceptual difference.

The last important conceptual difference between Subversion and Mercurial is not so important, but it can put you in an awkward position if you don’t know about it. Here it is:

Subversion is essentially a change control system for files , and in Mercurial change control is applied to the entire directory, including all subdirectories.

Mostly, it manifests itself in the following way: in Subversion, if you are in a subdirectory and make your changes to the repository, only changes from this subdirectory and all its subdirectories are made. This may cause you to forget to make changes from another subdirectory. And in Mercurial, all commands always apply to the entire directory tree. If your code is in c: \ code , then when you perform hg commit , you can be in c: \ code or in any subdirectory - the result will be the same.

This is not so important, but if you are used to having one giant repository for the entire company, in which some people only work with certain subdirectories that concern them, then know that this is not the best way to work with Mercurial. You'd better have many smaller repositories for each project.

And finally ...

Now the part where you just have to take my word for it.

Mercurial is better than Subversion.

Better if you work on the code in the team. Better if you work on the code alone.

Just better .

And remember my words, if you understand how Mercurial works, and you work like Mercurial, and you don’t fight this system, and you don’t try to do everything with Mercurial like you did in Subversion, but instead learn to work as Mercurial expects from you, you will be happy, successful, well-fed and you can always find a TV remote control.

And at first you will be tempted by the thought — I know it will be — to quit Mercurial and return to Subversion. Because it will be strange, as if you live in a foreign country, and you will be dragged back to your homeland, and you will come up with all sorts of excuses like claiming that in Mercurial, working copies take up too much space, that there is a bullshit, because they take up less space than Subversion. It's true!

And then you go back to Subversion, because you tried to make branches the same way as in Subversion, and got confused, and it didn't work out very well, because you actually had to make branches like in Mercurial, cloning repositories, not trying to do so, how it worked in Subversion, but learn the Mercurial-adopted method, which, believe me, works .

And after that you ask Jacob, or whoever you have the equivalent of Jacob in your office, to give you the cheat sheet “From Subversion to Mercurial”, and you spend three months thinking that hg fetch is like svn up , not really understanding what hg fetch does, and one day everything will go wrong and you will blame Mercurial, although you should blame yourself for not understanding how Mercurial works.

I know you will, because that's what I did.

Do not make the same mistake. Learn Mercurial, trust it, figure out how to do everything in its style, and you will advance a whole generation in the field of version control systems. As long as your competitors spend a week resolving conflicts that have arisen after the vendor has updated the library, you will type hg merge and say to yourself, “Oh dear, this is cool, it just worked.” And Mike will relax and share with trainees, and Spring, and the youth from the neighboring college will replace the down-padded coats with short torn T-shirts, and life will be good.

Continued here:
Hg Init: Part 2. The Basics of Mercurial