Question

Ok I know there's lots of controversy surrounding named branches, whether to use them or not, blah blah blah.

I'm coming from git, so named branches seem to me to be a bit like git branches which I like.

Now, we're also using repo branches as our deployment stages, so we have 3 repo branches for each app [development, staging, default].

So locally I work on the development branch, but use a named branch within that repo for features, then i merge back to default (on development) and push. Once I'm done with a named branch I close it.

Now however, when I pull my development branch repo into my staging branch repo and do a push, it gives me the:

abort: push creates new remote branches: some_branch! (use 'hg push --new-branch' to create new remote branches)

But I already closed this branch on the development branch repo before pulling it in. What's the deal?

In my staging branch repo, after the pull, hg heads shows one head, hg branches shows one branch so I'm at a loss as to where this named branch (some_branch) actually exists??

Answer 1

This is expected behavior in Mercurial. Even though some_branch is closed, it still exists in the repository's history and has changesets associated with it. As a result, by pushing, the named branch will be created in the remote repository and closed, just as it was in your local clone.

Even though a branch is closed, it still exists, but you won't be able to see it in hg branches because that would clutter things up.

Answer 2

You've basically hit the reason named branches are frowned on somewhat with hg. "named branches are forever" Which does not seem to be the case with the normal git development model.

The normal hg development model is to use anonymous heads for working on your changes (and merge your repo to a single head before pushing).

The git every-branch-has-a-name workflow has one advantage... in that your current progress is easily tracked by-name on that feature/bug/whatnot. The disadvantage is that the name disappears into the mists of time after trunk checkin. (ie, the thing you've been using to refer to the feature for the time when you're actively working on it is suddenly not a useful way of finding the csets) If this doesn't bother you, use a cloned repo, it has exactly the same feature and disadvantage. In particular, take advantage of Kiln's "branch repositories" feature to publicly track your development.

Part of the issue is that svn made no distinction between "feature branches" and "tagging branches" (Branches that needed to be tracked years later). git complicates this situation by explicitly using "feature branches" as part of the workflow. hg named branches are "tagging branches".

Named branches ARE useful in mercurial, any time you have a branch that really does need to live forever. In our case, code releases are tagged, but occasionally a customer wants "one little change" to tag "v1.3" (and won't take the up-to-date code 'v4.22')... in that case we fire off a named branch named 'v1.3-branch' and are able to track which patches are cherry-picked back to the branch. (We use 'destructive merges' to make the merge machinery work for us even in this case). All of these named branches (and release tags) are in a single "ReleaseRepository".