What's the best way to close a Mercurial branch?

Question

Is it better to first close a branch and then merge it with the default branch(for instance) or first merge it and then close it?

In TortoiseHg for instance, in the first case, you'll see a line from a close node to the default branch. In the second case you'll see a line from the last commit to the default branch and an extra line from the last commit to a close node.

I hope I'm clear. Maybe it's a matter of taste...

Answer 1

This isn't a matter of taste and there's a difference. In short, close the branch, then merge.

The thing is for Mercurial branch names is a mere "metadata" for each changeset. It does affect results of certain commands like hg branches omits closed ones, or hg push disallow addition of new head per branch by default. But again - it's filtering.

Internally, Mercurial sees repository as a graph of changesets, DAG to be specific. And topological heads of that graph are used for logic implementation, for example while comparing local and remote repositories during hg pull. Larger number of topological heads can (slightly, but still) affect performance - How do closed branches affect Mercurial performance?. As well certain number of them can cause 400 Bad Request from Mercurial running in IIS server - https://bitbucket.org/site/master/issue/8263/http-400-bad-request-error-when-pulling.

When one first merge and then close, the branch is close - all right, and human doesn't see that branch by default. But mercurial gets another topological head. Look below for visual explanation. Hence close first.

close then merge                merge then close
----------------                ----------------

@    default, head              @    default, head
|                               |
o    merge              <-->    | x  close branch, head
|\                              | |
| x  close branch       <-->    o |  merge
| |                             |\|
o |  dev on default             o |  dev on default
| |                             | |
| o  dev on branch              | o  dev on branch
| |                             | |
| o  open branch                | o  open branch
|/                              |/
o    default                    o    default

You may look here for details on how we came to this conclusion.

Answer 2

There is no real difference between the two methods when talking about named branches, at least in any recent version of Mercurial. Things were different pre-1.5(?), but purely in the fact that hg heads and hg branches would include these "closed" branches in their output - they still can if you specify -c on the command.

Rememeber that when you close a branch (using hg commit --close-branch or in Tortoise) you effectively just commit a new changeset where the change has a flag set to say that branch X is closed - you can easily update to the branch and re-open it by performing another commit.

However, when reopening a branch, the "bar" you see in Tortoise will still exist in the previously-closed changeset, and so for this reason alone I would personally opt for a close-then-merge policy. It is more visually instructive, I think, to see that you were merging from something you were happy with (and hence closed the branch prior to the merge).

Things are slightly different with "anonymous" branches, in that they are not included in the hg branches output when they have been merged in, and so don't require explicit closing.

Answer 3

As my company recently found out, there is a pretty good reason to prefer close-them-merge. As other answers have discussed, in merge-then-close you end up with an extra "topological head", whereas in close-then-merge you don't leave this extra head behind.

It turns out these extra heads add up, and can eventually cause problems in sync operations ( where Mercurial needs to negotiate which heads are on which side to discover the changesets to push or pull ). As the number of dangling topological heads grows, these operations get larger and larger, until eventually they start to fail. Thankfully, you can pretty easily clean them up later but it's probably best to avoid the problem in the first place.