Feature #63
feature branches?
| Status: | New | Start date: | 2011-01-19 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: |  Luis Figueira | % Done: | 0% | |
| Category: | - | |||
| Target version: | - |
Description
This isn't a feature request for the site, but for how we work with it. Should we be using bug/feature branches?
(As in: when I start working on bug or feature request X, I create a new branch in Hg called bug_X or feature_X and work on that, then commit with --close-branch [not supported by most GUIs including EasyHg, but we can work on that] when it's finished?)
The advantage of having lots of short-lived branches of this type would be to make it very easy to merge individual features to live without having to wait for other features being worked on by the same developer to become ready. The disadvantage is having very many branches (which e.g. easyhg doesn't cope too well with), more of a mental obstacle to starting work on a feature, and various other management-related questions that can be read about in blogs and stuff .
My view is that our branches would be short-lived enough and simple enough, and our "offline" communication easy enough, that the management problems wouldn't be too serious and we would generally find it easy to handle.
On the other hand, the tools we have with Hg are good enough that pulling occasional features and fixes from long-lived branches is also reasonably simple to do, so long as we don't have to do it too often (it can mess up the history even if it's simple to do).
I think it's worth a go. What d'you think?
History
#1
Updated by Chris Cannam over 13 years ago
btw, this is prompted by my having just merged some fixes from my own branch, except that my own branch has in the mean time been updated for test purposes to a newer build of the underlying Redmine core that we don't want to merge, so the merge involved extracting a series of changesets and... it was just a bit too fiddly, basically. But it did work in the end.
#2
Updated by Chris Cannam almost 13 years ago
Well, I think feature branches are working pretty well so far.
However I've been following an interesting thread on the Mercurial mailing list in which it's made clear that this is considered quite bad practice -- because Mercurial's design does not scale well with the number of named branches (or tags) in the repo. Since it's not possible to delete branches (you can close them, but I guess Mercurial still tracks them, it just labels them as closed) this could well lead to problems later.
In practice perhaps this is only an issue once you have many thousands of branches, but it does suggest that the basic principle is flawed and that it may not be a good habit to get into.
I am also slightly nervous about the fact that our branch names are now tied down to our tracker entries -- if we ever switched tracker for a project (for example) there would be no easy way to start again with feature branch names.
The recommended solution to both of these problems is bookmarks, which are (potentially) short-lived labels tracking what would otherwise be anonymous heads in the style of Git branches. These are a newer addition to Mercurial, not supported in EasyMercurial at all yet and I've never really played with them -- we should do some tests.
The mailing list thread is here -- the linked message mentions some possible pitfalls of bookmarks as well.