Mercurial Release Management

Question

I am using mercurial for source control. I want to have a main dev branch, and then have points in time that align with say "v1.0" "v1.01" and "v2.0", so that at any time I can pull down say "v2.0" and crush some bugs on it. I have heard some people say I need tags, some say I need bookmarks, others say I need named branches, and still others say I just need to maintain multiple cloned repositories.

From my point of view, multiple cloned repos seems like a poor choice because one thing I like about DVCS is that once you clone "the" repo, you have all past history and can totally restore from someones laptop if your central server burns down. If your repo is split up all over the place, I feel like you lose this benefit, unless you expect people to clone 5 repos and maintain them on their computers locally. This concerns me because the majority of people say that this is a good way to do it, yet it logically doesn't make sense to me. (I understand this is not a proper way to do backups, but not having full access to a part of the repo without going back to the server seems odd to me)

So to me, the way to keep everything together must be either tags, named branches, or bookmarks. However, I can't seem to differentiate these. People tend to explain bookmarks as "kinda like tags, with some caveats" and named branches as some kind of a moving tag that is probably better done with clones.

I really like git style branching (single repo, multiple branches off of it), however, I do not want to resort to weird plugins or hacks to make it look like git. I want to understand the proper mercurial way.

Bonus: how do "small-scale" branches fit into the mix, i.e. you want to work on a small feature in its own branch?

Answer 1

Named Branch - in each commit you make there is a field for which branch the commit is against. Other than that there is no difference between a repo with a named branch and a repo with multiple heads. When you merge named branches it is just like regular merging and the branch name is taken from your currently active branch. This is more than likely what you want for long term v1.x branch.

bookmarks - floating tags much like tip in your repository. Local only unless you do some sort of side band synch. Good for doing feature branches or something where you need to keep track of what is going on but don't need to share with others.

Tags - A named commit good if you need to know exactly what was released at v1.0

I would use name branches for development a 1.x branch a 2.x branch etc. Then use a tag to label what actually went out as version 1.0, 1.1 would be done on the 1.x tree then 1.1 release would be a tag of what was in it. I wouldn't make bookmarks part of the flow since you have to synch them manually.(Note in newer versions of mercurial bookmarks can be synched remotely though it still takes user intervention.)

Answer 2

I've never understood the idea of having cloned repos as anonymous branches.

hg branch feature-name is how I like to roll.