3

I've used mercurial for some time now, but haven't really gotten used to working with branches, so I am struggling to figure out whether this workflow makes sense or not before applying it to a real project.

The question:
Does it really make sense to resurrect a development branch every time we're going to work on a new release by merging production into it, or should we instead make unique named short-lived development branches like development-1.1?

Description of workflow:
Every production-ready revision of our code will be tagged (1.0,1.1 and so on) and placed in the production branch. As soon as we've put 1.0 into production, we immediately start working on next release - 1.1, by opening a branch named development, which is then sub-branched by every developer for every assigned feature to keep things neat. Very straightforward this far.

The development branch, now containing the in-merged feature branch, is then tested and merged back into production as the changes have been considered production-ready.

When when we need to continue working on an upcoming release, 1.2 in this example, we merge the production-branch into the development one and start working.

Illustrated history of the revisions:

@ changeset: 8:21e89b501d4e |\ branch: development | | tag: tip | | description: Development stage for v1.2 opened by merging production into development. | | | o changeset: 7:920ca77aa956 |/| branch: production | | tag: 1.1 | | description: Version 1.1 stable (merged from development). | | o | changeset: 6:691b7aa99e42 |\ \ branch: development | | | description: Feature merged in to development | | | | o | changeset: 5:5156cb9cf556 | | | branch: feature | | | description: Feature finished | | | | o | changeset: 4:0345dc73e144 |/ / branch: feature | | description: Work started on a feature | | o | changeset: 3:9d49be5d8a03 |/ branch: development | description: Development branch opened | o changeset: 2:ba818420fa88 | branch: production | tag: 1.0 | description: Version 1.0 stable. Woop woop!
Improve this question

2 Answers 2

Reset to default
6

With Mercurial named branches are forever, and thus the general advice is to only use them for names that always apply. Things like "stable" and "development", not things like "bug-194534" and "release-1.1". This is explained nicely in the wiki.

For things that have finite lifespans you're better off using something like bookmarks which are much closer to what git calls branches than are Mercurial named branches. Other great options for short-lived concepts are anonymous branches or clones, both of which are non-permanent.

The general advice is to use default as your development branch, but in brief, yes, keep reusing your same branch for development.

Improve this answer
Sign up to request clarification or add additional context in comments.

5 Comments

"the general advice is to only use them for names that always apply" - don't pretend to give it at general advice, it's lie. Quote from wiki "...if you attempt to use a branch per bugfix, you may eventually run into performance issues. Mercurial is designed to work well with hundreds of branches. It still works quite well with ten thousand branches..."
@LazyBadger: I agree with you, but it's not Ry4an's fault. He's just following the party line — Matt's stance is that named branches should not be used per-bug, but there are companies that do that just fine. Like I've written before, it seems like it's mostly a GUI problem.
@LazyBadger "lie" seems a little strong. I said it's the "general advice" which is true (see the link). I never asserted it's a technical necessity.
@Ry4an - ok, Bringlish isn't my mothetongue. And quoted by me wiki part doesn't make you note as general advice, because anybody can make own decision based on own conditions
That text was written by Matt, Mercurial's creator: mercurial.selenic.com/wiki/… I didn't say it was an edict. I said it was advice. I'm sure @industrial is quite aware he's free to disregard advice without your clarification.
1

the workflow you are describing seems reasonable in that it's similar to the git-flow workflow.

http://nvie.com/posts/a-successful-git-branching-model/ .

It's popular(i guess), so it would be reasonable to expect any developer to understand it. That's got to be worth something. I don't know what additional value could be had by varying it with a short lived dev-1.1 branch etc. it seems like the overhead of managing those would probably outweigh the cost.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.