[IPython-dev] Why trunk-dev (i.e. long-lived branches) may be a bad idea
Ville M. Vainio
Wed Sep 17 15:23:31 CDT 2008
Some thoughts about long lived branches (i.e. a branch that goes on
indefinitely) & optimizing our workflow:
- Clicking on "branch merged" on launchpad does not make any sense for
the long-lived-branch scheme (which in part suggests that this is not
the way bzr is meant to be used)
- All branches should be as close to the trunk as possible (i.e. it
should be clear when it was branched, and when it was merged). If you
merge back-and-forth between trunk-dev and trunk, you lose sight of
what has really been happening - and it's impossible to tell by just
looking at revision graph and branch names.
- The point where you had "clean slate" is not visible in history.
Of course this is only a problem if you do lots of back-and-forth
merging. If you push trunk over your trunk-dev after merge (or rather,
just before starting to develop something), the history stays easily
Perhaps this could be a scheme that is as "relaxed" as using trunk-dev
*appears to be*, in that it doesn't require you to think of branch
name before you have actually done someting:
1. When you start developing, push trunk over trunk-dev
2. Commit to trunk-dev normally
2. When you have set of changes about "something" ready, push
trunk-dev to launchpad under different name (ipy-done-something). Mark
that branch as "request review & merge". When that is done, merge and
mark the branch "merged"
3. Go to #1.
The idea here, among other things, is to retain review comments etc.
neatly associated with the branch where they occured.
Ville M. Vainio
More information about the IPython-dev