Idioms of use with bzr-svn -- Bazaar/Launchpad workflow issue

[Stephen J. Turnbull]

Russel Winder writes:

 > --  There are two sets of changes here which really ought to be in
 > separate feature branches and yet in order to use the fork, all the
 > changes need to be present in a single branch.  Continually merging from
 > two feature branches to create a using branch seems excessive overhead.

Why do you think that's excessive?  If they're separate feature
branches, then they should not conflict very much.  Most merges should
work without conflict.  The using branch will eventually be thrown
away, so you can just keep merging to it from each feature branch
without worrying about whether its history makes any sense.

Mercurial (git) people often use mq (stgit) in this kind of situation,
but that tends to lose the history of the branch, or require that you
use a patch per proposed commit in the branch.  bzr pipelines are a
bit better than mq in terms of keeping history, but I'm not sure how
well they work with multiple pipelines cooperating.  bzr looms may be
exactly what you are looking for, but I haven't used either pipelines
or looms in anger, only in toy examples where the extra commands were
literally more trouble than they could possibly save.

 > --  Rebasing means that conflicts between changes in the mainline and
 > the local amendments are apparent early.  Not rebasing means that you
 > can get a whole slew of conflicts when trying to make patches -- or a
 > final rebase as part of the overall merge and death of the "fork"

You can merge progress in the mainline into each feature branch
separately.  bzr will in general be smart enough to avoid conflicts
when merging the feature branches into a testing branch.  This isn't
as pretty as rebasing, but (with current technology) you can't rebase
public branches anyway.

 > The above (or something analogous) strikes me as being an instance
 > of a common situation.  It therefore should have a standard
 > workflow model.  My first reaction is that I have just failed to
 > find the right place in the Bazaar documentation . . .

This is the problem that Darcs is supposed to solve.  It doesn't
though.  It simply exchanges some problems for others (specifically,
Darcs loses or conceals a lot of history when it commutes patches).