CODEWITHSUNDEEP
mercurialdvcs
Jade Somath
Jade Somath

Reputation: 173

Mercurial Release Management

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?

Upvotes: 10

Views: 765

Answers (5)

Yawar
Yawar

Reputation: 11607

You need tags to mark the releases of v1.0, v1.01, and v2.0 etc. For branchy development (bugfixing, feature branches etc.), you can use bookmarks--they are by now very well supported in collaborative use (see http://mercurial.aragost.com/kick-start/en/bookmarks/#sharing-bookmarks). If you need to have long-lived branches (i.e. they will be in the repo for the foreseeable future) use named branches. They would be a good choice e.g. for having v1, v2, ... branches of development.

You could use solely bookmarks or solely named branches for both short-lived and long-lived branches, but it's becoming standard practice to prefer bookmarks when you can.

See also mercurial: mix named branches and bookmarks for a quick and graphical answer on how bookmarks and named branches are different.

Upvotes: 0

Nick Pierpoint
Nick Pierpoint

Reputation: 17769

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 recommend you tag each release version.

If you need to release a bug fix to a previous version, you would first create either a named branch or clone a new repository based on the version tag. Once you've worked the bug you would merge the bug fix back into your main development branch.

It really doesn't matter whether you use a named branch or a clone as the result is the same: the bug is fixed, the fix is released to the previous version, the fix is incorporated into the main development branch. Read other answers, give both methods a try, and use the one you prefer. Personally, I use named branches for these long-lived release branches so that all the history of each application release is stored in a single repository.

So... tag each release and branch "on demand".

Upvotes: 0

Paul Nathan
Paul Nathan

Reputation: 40309

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

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

Upvotes: 2

stonemetal
stonemetal

Reputation: 6208

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.)

Upvotes: 2

pyfunc
pyfunc

Reputation: 66709

DVCS like Mercurial or Git makes it easy to clone a repo. That does not mean you use it for purpose of your release management workflow.

That every one has complete mercurial repo is only a side effect of DVCS. It means that there is a redundancy when the main repository is some how lost.

You could work with DVCS in a way that you could have a master repository where you could push changes and pull changes from, just like a client-server VCS (subversion) with the added advantage that you could work offline.

For your release management workflow, you should still look at

  1. bookmark, tags and branches.

There are enough discussion on SO on each of these topics.

The following provides a good brief information on branching with clone, bookmark and named branches

Upvotes: 0

Related Questions