Bazaar Mercurial Plugin to access BitBucket

[Stephen J. Turnbull]

Ben Finney writes:
 > "Brendan Simon (eTRIX)" <brendan.simon at etrix.com.au> writes:
 > 
 > > So the big question is ..... why use Bazaar instead of Mercurial ??
 > > Given Bazaar is no where near as widely used, what makes Bazaar so
 > > different, so much better, that I should stay with Bazaar ??

First a few responses to Ben's comments, then a list of my own:

 > * Multiple workflows applicable in different situations, all compatible
 >   with each other, which can be chosen by the individual developer
 >   without requiring anyone other collaborator to adjust, and changed
 >   later just as easily.

This is not true of centralized workflows, by definition.  It's true
that by choosing to use a bound branch one can ensure serialization of
one's own commits, but it doesn't help you straighten out the rat's
nest that others' commits can create.

Multiple workflows is a real advantage (see my list below), but to my
mind this is more on a project level.  Mercurial (or *any*
decentralized version control system) is pretty much just as good at
allowing individuals to work as they please.

 > * The shelve plugin, well-integrated and mature, allows selected changes
 >   to be put aside if they're not ready to be committed – and the
 >   remaining changes to be tested *before* they're committed. (This is
 >   superior to the “hg record” style, since the latter doesn't give the
 >   opportunity to test the actual set of changes before committing.)

It's true that hg requires a commit, but the commit may actually be a
qrefresh.  hg qpop and you have a testable workspace.  shelve may well
be a more convenient workflow, though.

 > * The pipeline plugin, providing a well-integrated way to maintain a
 >   branch of development as a sequence of changesets against trunk, for
 >   easy submission upstream as patches. This is much simpler to get right
 >   than the “queues” of Mercurial, IME.

What's to "get right"?  If you're going to submit as patches, you just
do that, qpop and qdelete.  If that's *all* you're going to use the
feature for, again pipelines may be more convenient than the
equivalent Mercurial workflow.  But queues are very powerful,
especially when combined with record.

The big problem I have with queues is the name: in actual practice
it's a stack. :-)  You don't really notice the queue nature when
"finalizing" queued patches, which is the part of the UI that's FIFO.

 > * Merged revisions are hidden by default. This obviates, AFAICT, any
 >   need for changing history (so-called “rebase”) before publishing a
 >   branch.

You've criticized rebase many times, but I still disagree.

Rebase is no more and no less than using a centralized workflow after
the fact.  If you don't like the history-changing aspect of rebase,
you should be just as unhappy with bound branches/lightweight
checkouts.  In the bound branch, the developer is stuck with the
choice of saving up her changes and committing them in one go,
typically on top of others' commits which were not the context in
which she originally developed her changes, or interleaving her
commits (which may be complete as "steps" but not provide a complete
feature) with others' unrelated commits (and "falsifying history" --
ie, the actual development context -- with each one).

 >  \         “Science is a way of trying not to fool yourself. The first |
 >   `\     principle is that you must not fool yourself, and you are the |
 > _o__)               easiest person to fool.” —Richard P. Feynman, 1964 |

;-)

To me, aside from the possibly superior merge algorithms, which if
true would be a major advantage, the advantages bzr offers are

(0) fits most people's mental model of version control better than the
    wildly-flexible git or slightly tamer Mercurial models; specifically:

(1) implementation of a genuine mainline (what Ben refers to as
    "hiding merged revisions"), from which other branches diverge and
    then are merged to;

(2) flexible configuration and commands that allow implementing many
    common workflows with natural command sequences, i.e., without
    forcing the developer to follow complicated rules;

(3) proper rename/merge tracking, including directories;

(4) patience diff by default;

(5) lightweight checkouts (ie, history-less workspaces which refer to
    another branch for all history operations); and

(6) explicit commitment to portability (specifically, Windows).

I'll echo Ben here: there may others that I'm unaware of.

On the downside, the big disadvantage in the past was that all of the
above comes at a cost of substantial complexity in the representation
of history and configuration, and attendant annoyance of format
conversion (subversion 1.7 just did that to me ;-) and performance
problems -- as I said, in the past.  Currently bzr is as performant in
terms of repo size and speed as git and Mercurial on POSIX filesystems
for basic operations like clone, and clearly beats git in many cases
on Windows.  I don't know about Mercurial, but I would guess it is
also tuned to filesystems with POSIX semantics, so bzr is probably the
most performant on Windows.  However, new use cases do occasionally
bring out minor performance problems, and often the bzr devs
themselves at first don't understand why these problems occur.
They're good about fixing them anyway, though!

The remaining disadvantage is that it's not git.  But then, I'm given
to understand that most people have trouble understanding that as a
disadvantage. :-)