[IPython-dev] Why trunk-dev (i.e. long-lived branches) may be a bad idea

[Ville M. Vainio]

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

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
http://tinyurl.com/vainio