Will re-basing support be added into Bazaar core ?

[Russel Winder]

David,

On Mon, 2009-04-20 at 01:47 -0500, David Timothy Strauss wrote:

> It can be "evil" from the perspective that existing branch history is
> sacred and should not be altered. This sacredness has a good
> justification: if you can muck with the history, you can render
> previously committed work irretrievable. Commits should be durable, at
> least to activity done through the Bazaar CLI. Of course, we violate
> this durability now, but that's not an argument for allowing further
> violation of durability.
> 
Clearly the mainline or any branch designated as immutable must be
immutable as far as history is concerned.  No argument there.  This
militates in favour of a "not rebaseable" flag in the branch metadata.

> I also have to question the purpose of rebasing and whether there's a
> different, innovative alternative that also solves the (alleged)
> workflow problems rebasing is used to solve. I've done some pretty
> crazy feature/vendor/etc. branches for Drupal, and I've not needed to
> rebase. I'd like to see some realistic use cases that only rebasing
> can currently solve.
> 
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.

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090420/966af9aa/attachment.pgp