Re: transplanting to the 3.4.0 branch

[Jordi Gutiérrez Hermoso]

On 2 March 2011 07:03, Ben Abbott <address@hidden> wrote:
> I've been negligent in mentioning when changesets should be
> transplanted.

This is one problem with this transplanting approach. It really is
duplicating work, both in duplicating the actual bytes (the
changesets) and in making both the patcher and the release manager
remember to transplant patches. You have to notify when patches should
be transplanted, you may forget, and the release manager may actually
have to do a lot of work to merge if they take too long to transplant
or if the two branches have diverged too much.

I really think we should be patching directly on the stable branch
when it needs to be patched and merging those patches into the default
branch when it needs to be merged (usually immediately). During
release time, the release manager can have a separate sanctified repo
in order to do quality monitoring. I've said it before: don't be
afraid of branchy development. Branching and merging is natural in hg,
and not doing is like refusing to turn a bus right or left at
intersections because we've always been driving a train on a fixed
track before.

Mercurial itself works this way. Matt Mackall (mpm) has a sanctified
repo and there's a "crew" repo where development normally happens. mpm
is the one who decides what goes into the sanctified repo (i.e. when
and what he pulls), and everyone else keeps pushing to the crew repo
as usual.

- Jordi G. H.