Help understanding the benefits of branching in Mercurial

I've struggled to understa开发者_JAVA百科nd how branching is beneficial. I can't push to a repo with 2 heads, or 2 branches... so why would I ever need/use them?

First of all, you can push even with two heads, but since you probably don't want to do that, the default behavior is to prevent you from doing it. You can, however, force the push to go through.

Now, as for branching, let's take a simple scenario in a non-distributed version control system, like Subversion.

Let's assume you have a colleague that is working in the same project as you. The current latest changeset in the Subversion repository is revision 100, you both update to this locally so that now both of you have the same files.

Ok, now your colleague has already been working on his changes for a couple of hours now, and so he commits. This brings the central repository up to revision 101. You're still on revision 100 locally, and you're still working on your changes.

At some point, you complete, and you want to commit, but Subversion won't let you. It says you have to update first, so you start the update process.

The update process wants to take your changes, and pretend you actually started with revision 101 instead of 100. If your changes are not in conflict with whatever it was your colleague committed, all is hunky dory, but if your changes are in conflict, you have a problem.

Now you have to merge your changes with his changes, and things can go haywire. For instance, you might end up merging one file OK, the second file OK, or so you think, and then the third file, and you suddenly discover that you've got some of the details wrong, it would've been better to merge the second file differently.

Unless you made a backup of your changes before updating, and sooner or later you will forget, you have a problem.

Now, the above scenario is actually quite common. Well, perhaps not the merging part, it depends on how many is working in the same area or files at the same time, but the "must update before committing" part is quite common with Subversion.

So how does Mercurial do it?

Well, Mercurial commits locally, it doesn't talk to any remote repository at all, so it won't stop you from committing.

So, let's try the above scenario again, just in Mercurial this time.

The tipmost changeset in the remote repository is revision 100. You both have cloned this down, and you're both starting to work on the changes, from revision 100.

Your colleague completes his changes and commits, locally. He then pushes his changeset up to the central repository, bringing the tip there up to revision 101.

You then complete your changes, and commit, also locally, and then you want to push, but you get the error message you've already discovered, and is asking about.

So how is this different?

Well, your changes are now committed, there is no way, unless you try really hard to accidentally lose them or destroy them.

Here's the 3 repositories in play and their current state:

Colleague       ---98---99---100---A

Central         ---98---99---100---A

You             ---98---99---100---B

If you were to push, and was allowed to do this (or force the push through), the Central repository would look like this:

Central         ---98---99---100---A
                               \
                                +--B

Two heads. If your colleague now pulled, which one should he continue working from? This question is the reason Mercurial will by default prevent you from causing this.

So instead you pull, and you get the above state in your own repository.

In other words, you can chose to impact your own repository and create multiple heads there, but you are not imposing that problem on anyone else.

You then merge, the same type of operation you had to do in Subversion, except your changeset is safe, it was committed, and you won't accidentally corrupt or destroy it. If, mid-merge, you want to start over, you can, nothing lost, no harm done.

After the merge, your local repository looks like this:

You             ---98---99---100---A----M
                               \       /
                                +--B--+

This is now safe to push, and if your colleague now pulls, he knows that he has to continue from the M changeset, the one that merged his and your changes.

The above description is what happens due to Mercurials distributed nature.

You can also name branches, to make them more permanent. For instance, you might want to name a branch "stable", to signal that any changesets on that branch have been thoroughly tested and is safe for release to customers or to put into production. Then you would only merge changes onto that branch when said testing has been completed.

The nature, however, is the same as the above description. Whenever more than one person works on a project with Mercurial, you will get branches, and that's a good thing.

Whenever more than one clone of a repo is made and commits are made in those clones, branches happen, whether you name them by using the hg branch command or not. My philosophy is, you might as well give them a name. It makes things less confusing.

A good explanation of mercurial branches: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/