Bazaar Mercurial Plugin to access BitBucket

[Stephen J. Turnbull]

Barry Warsaw writes:

 > * Sane revision numbers.  Yes, I know why hashes are there, and all three
 >   dvcs's have them, but they are very much user *un*friendly.  I like that
 >   Bazaar generally makes them a hidden implementation detail rather than a
 >   constant visible thorn.

This depends on the "distinguished mainline" philosophy.  Since most
bzr users like that philosophy a lot, it's no problem at all, and works
really well.  See also "floppy mainline" below.

 > * No colo by default.  Yes, I get that some people *love* colocated
 >   branches, but I think they lead to lots of extra cognitive load
 >   and pain (e.g. Python's no-new-heads policy).

Colocated branches may make it easier to push new heads, but the real
issue is concurrent development.  Emacs also found it needs a "sorry
but you're not allowed to push that" policy although it is a bzr shop.

The problem shows up somewhat differently in bzr, as a "floppy
mainline": if a developer merges *from public into private* instead of
the other way around, then suddenly his local commits become the
public mainline when he pushes -- and all the revnos since the fork
change.  But at root it's the same problem: concurrent development ==
multiple heads in the project, which must be merged to give definition
to the mainline.  In bzr's case, merged in the correct direction.

For developers experienced in such workflows, it may be that no
constraint is necessary.  But I would not set up a project repository
in Bazaar without configuring the appropriate policy to protect the
mainline (I think it's "bzr init --append-revisions-only").  Wrong-way
merges are an attractive nuisance in Bazaar.

 >   One-branch-per-directory for me please.  (Yes, I know that you
 >   can make hg for example seem to act this way, which is how I work
 >   with the Python repo.  But it's unnatural and leads to merging
 >   problems unless you do things just right.)

Not "seems", a standalone Mercurial branch is a standalone branch in
the same way as in Bazaar.  And that's the default for Mercurial.  You
have to do something quite deliberate to make it use colocated
branches.  Python just did something not very useful IMO in choosing
named branches for organizing its public Mercurial repos, more or less
forcing multiple heads on all users.

XEmacs' Mercurial repo has a repo-per-branch organization with no
on-going need for a no-new-heads policy.  The reason is that Mercurial
fundamentally doesn't care about the direction of merge since there's
no distinguished mainline.  We do have a new head block on all our
repos, but it's a no-op so far for typical developers -- nobody ever
asks "why can't I push?" because they can't commit until they merge --
and then there aren't multiple heads.  We did have one incident with
named branches, that annoyed people because a named branch ended up as
tip, and just recently we've been using subrepos and a "helpful"
commit in the parent repo caused "can't push" error.  So far nobody
has been tempted by named branches again (I really don't think they're
natural in Mercurial), and the "helpful commit" is a minor VC
annoyance; there are much more important workflow reasons why that's a
Very Bad Thing.

I don't have an opinion on whether subrepos could cause confusion via
multiple heads in other workflows, but I'm pretty confident that they
won't in ours.

Note that none of the above in any way indicates a disadvantage of
Bazaar, just that they're not really disadvantages of Mercurial either,
but rather of the way a particular project configures its repos.