Bazaar Mercurial Plugin to access BitBucket

[Stephen J. Turnbull]

David Muir writes:

 > I'm surprised nobody has mentioned Mercurial's named branches,
 > bookmarks, anonymous branches, etc. Finally settled on using named
 > branches for everything, as the others do a fast forward pull (if it
 > can) when you try to merge back into default (trunk).

Well, this is a thread about Bazaar's advantages.<wink/>

I really dislike Mercurial's named branches.  They're not branches in
the usual VCS sense of "ancestry back to the root", but rather a
partition of the nodes in the DAG.  I'm not even sure named branches
are guaranteed to be contiguous sets, and I find it very disconcerting
that fork and merge nodes are not part of both branches.  It *is* nice
for forensics to be able to identify a branch's nodes after a merge.
(This comes up if you close a feature branch, and then discover later
that you need to do a bunch more work on it, but want to restart from
the merged state.  git branch refs don't help you deal with this, and
you can't even use the merge parent order to identify anything except
the mainline.  I use a tag on the premerge node, which is suboptimal,
but easy enough to apply during forensics if I didn't bother at merge
time.)  But given the cognitive dissonance created by opposing named
branches to "real" branches, I'm happy to forego the former.

I also (as described elsewhere) think that deliberately introducing
multiple heads into a model that isn't designed explicitly to manage
multiple heads is confusing unless the project already has the right
kind of workflow.

A bookmark looks to be just what git calls a "branch ref".  It seems
to me that this is the right way to manage multiple heads, but my
project very carefully avoids multiple heads, so I haven't tried them
in the context of Mercurial.