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!
Industrial
  • 41,400
  • 69
  • 194
  • 289

2 Answers2

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.

dype
  • 500
  • 1
  • 4
  • 15
Ry4an Brase
  • 78,112
  • 7
  • 148
  • 169
  • 3
    "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..." – Lazy Badger Feb 06 '12 at 04:42
  • 2
    @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](http://stackoverflow.com/a/8870937/110204), it seems like it's mostly a GUI problem. – Martin Geisler Feb 06 '12 at 08:42
  • @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 Brase Feb 06 '12 at 15:59
  • @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 – Lazy Badger Feb 07 '12 at 00:09
  • That text was written by Matt, Mercurial's creator: http://mercurial.selenic.com/wiki/StandardBranching?action=diff&rev1=3&rev2=4 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. – Ry4an Brase Feb 07 '12 at 01:51
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.

Tom Willis
  • 5,250
  • 23
  • 34