Maintaining trunk and stable branch

[Eric Siegerman]

On Sun, 2011-02-20 at 20:02 +0100, Timo wrote:
On 20-02-11 15:27, Frits Jalvingh wrote:
> > For this to work you must make the fixes on the stable branch, and
trunk
> > must have been stable at one time, i.e. you created trunk by just
making
> > another branch (copy) of stable.
> This is not the case I think. Trunk contains commits of new features 
> that stable doesn't has.

I think all Fritz means is that the "trunk" and "stable" branches
must be descended from a common ancestor.  Since you say you
created "stable" by branching it off from "trunk", this is the
case; it doesn't matter whether you branch A from B or B from A;
Bazaar can still handle it.

What would not work is to:
  - import a source tarball into a "trunk" branch
  - import it again into a "stable" branch
  - try to merge between the two branches
That's because, although you would know that foo.py in one branch
is "the same file" as foo.py in the other, Bazaar would *not*
know that.  But as I say, it doesn't sound as if this is the
situation you're in, so Bazaar should let you merge back and
forth as you please.

That brings us to the question of what does in fact please you:

> Hmm, but what if I spend 2 weeks fixing bugs on stable, trunk still 
> suffers from these bugs in the meantime. So that brings back my first 
> question: should I merge stable into trunk after each commit?

I don't think there's a general "should" about this; it's up to
you.

You're right; the longer you wait to merge your bug fixes from
"stable" into "trunk", the longer you have to live with the bugs
in "trunk".  But every time you do such a merge, there's a small
risk of destabilizing "trunk", and having to spend some time
sorting things out.  But the longer you wait between merges, the
higher the risk *on each individual merge*, because the branches
will have diverged more, and the longer it might take you to sort
things out (partly because the bug fixes from two weeks ago are
no longer fresh in your mind).

So there's no hard and fast rule.  It's a tradeoff, which you can
only learn to make with experience with your project, team,
working style, etc..

I haven't tried this approach yet, but it sounds promising as a
way to help keep straight what bugs have been fixed where:
    http://wiki.monotone.ca/DaggyFixes/

> Maybe I'm doing something fundamentaly wrong or don't get the whole
concept.

I don't think so; judging by the questions you're asking, you
seem to be on the right path.

  - Eric