Will re-basing support be added into Bazaar core ?

David Timothy Strauss david at fourkitchens.com
Mon Apr 20 08:34:38 BST 2009

----- "Russel Winder" <russel.winder at concertant.com> wrote:

> This is of great interest.  To date I have found no alternative to
> rebase for keeping my feature branch changes "on top" of a mainline I
> am tracking.  Perhaps though I am too steeped in Subversion mindset?  Or
> perhaps this is a "Subversion repository as mainline but not allowed
> to store Bazaar branches" problem only?  If there is a way of avoiding
> rebase and yet not having conflicts caused by changes in the tracked
> branch, I would like to hear about it.  I am happy using rebase when
> I have to, but if I can avoid it without tortuous sophistry and
> doublethink, I am all for it.

(1) You branch from the mainline to develop a feature.
(2) You work on your feature branch.
(3) The mainline chugs ahead.

(4) Prepare for merging the feature back into the mainline: (choose one)
(4a) Your workflow: Rebase off the mainline.
(4b) My workflow: Merge from the mainline back into the feature branch.

(5) Resolve conflicts on the feature branch.
(6) Merge the feature branch into the mainline.

Either way, the result is the same: a common ancestor between the feature and mainline branches with changes only on the feature branch since the ancestor. This makes the feature -> mainline merge trivial, which I believe is your goal.

I'd like someone more familiar with Bazaar internals to verify my ancestry statement, but my experience corroborates it. I used the "merge from mainline" workflow periodically on the Drupal Fields in Core project to maintain mainline-ready code.

> > At this point in my arguments, you're probably thinking, "So, just
> > don't use rebasing." But I strongly believe that Bazaar core should
> > provide a safe, coherent set of tools by default. Throwing every
> tool
> > and option at users is confusing for beginners and dangerous for
> > intermediate users. For each problem, we should try hard to find
> one
> > really great solution rather than build a smattering of related
> > utilities (like rebase) that can cleverly be combined to solve the
> > problem.
> Again, no argument from me, I am entirely happy with the features the
> rebase plugin gives me.
> The problem arose because OP felt that perhaps rebase was not getting
> the rigorous testing/development that the core was getting.  For me
> this
> is a different issue to "put rebase in the core", it is about having
> the
> same quality control over plugins as over the core.
> This leads me to think that there needs to be some form of quality
> control statement about the plugins, especially the ones publicized
> formally on the Bazaar website.  People need to know if a plugin is
> an
> officially maintained one or just a contributed one, and, as a
> separate
> orthogonal measure, what level of testing and quality control the
> plugin
> has.  Agreed this adds overhead but as Bazaar faces up to corporate
> use
> and corporate installation procedures these sorts of measure will be
> important. 
> -- 
> Russel.
> ============================================================
> Dr Russel Winder                 Partner
> Concertant LLP          t: +44 20 7585 2200, +44 20 7193 9203
> 41 Buckmaster Road,     f: +44 8700 516 084    voip: 
> sip:russel.winder at ekiga.net
> London SW11 1EN, UK.    m: +44 7770 465 077    xmpp:
> russel at russel.org.uk

David Strauss
   | david at fourkitchens.com
   | +1 512 577 5827 [mobile]
Four Kitchens
   | http://fourkitchens.com
   | +1 512 454 6659 [office]
   | +1 512 870 8453 [direct]

More information about the bazaar mailing list