Bazaar Mercurial Plugin to access BitBucket

[Stephen J. Turnbull]

Barry Warsaw writes:

 > >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.
 > 
 > I have a vague feeling that colocated branches are preferred by
 > folks working on large compiled language code bases, but
 > personally, I don't see the attraction or advantage of them.

You're thinking from a coding standpoint.  s/working on/managing/ and
s/compiled/insanely active/ will help, I think.  Ie, from a project
management standpoint, a coloc repo is like having a roadmap, a
standalone branch is a TripTik.  The TripTik is pretty useless if you
want to navigate around a massive traffic jam!

 > >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.
 > 
 > Interesting point.  What I got out of that discussion (possibly
 > misunderstanding) is that it was a more natural fit to Mercurial's
 > biases[1].

No, I think that while the proponents had their own biases, they
carefully considered the (unique in my knowledge of volunteer
projects) requirement that *four* active branches be managed by *most*
developers simultaneously, with some developers dealing with *six*.

 > But maybe it was just the best fit for those biases based on the
 > workflows expected in Python, e.g. fast-forward merges among
 > versions in a major version (e.g. 3.1->3.2, but not
 > 2.7->3.x).

Exactly.  The point is that because most of the time each patch will
be applied to multiple branches it is useful to bundle those branches
together at clone time.  For the branches in a major version sequence,
it may also be convenient to use a colocated workflow in development,
where you

(1) identify a needed change in any convenient branch
(2) make a throwaway branch from the convenient branch
(3) do the work
(4) cherry-pick from throwaway to the lowest relevant branch
(5) checkout the next branch and merge
(6) repeat (5) until done

(2) is very convenient in an environment that supports colocated
branches, but I think I would find it tedious and annoying in a
standalone branch environment, and would just work in one of the
public branches and use a null merge if necessary.  An alternative
would be to use something like bzr pipelines or Mercurial queues that
operates on patches, and once done with the patch apply it to the
lowest relevant branch.

In development, the switch in step (5) could be just as well done with
a cd or via a bzr switch in a lightweight checkout, I guess.  But from
the management standpoint, the user lacks a global view of all
branches simultaneously.  For example, CPython tip as I write this is
http://hg.python.org/cpython/graph/cfc042ca551a (r73043).  In a
non-coloc, you would still be able to see r73042, but not r73037 (tip
of 2.7 as I write this).  But maybe you don't much care about 2.7 when
working on 3.x, the patch probably won't come close to applying as is.

Now consider the view from r73042.  In a non-coloc branch, you not
only can't see activity on 2.7, but you wouldn't be able to see
activity on default or 3.2, either.  This would bug me a lot, but
YMMV.  Of course, if there are more than one or two developers in
Python who feel as I do, using coloc branches gives them the "view
from space" they want, and in theory shouldn't cost you anything.
Just bite the space bullet, have multiple repos, check out the
relevant branch for each at initialization, and never checkout a named
branch in any repo afterward.  (Evidently that does *not* work for
you, all this is pure theory so ignore it in practice.<wink>)

To my mind[1], coloc is a no-brainer here, it ties all the aspects of the
patch workflow together with one concept, and provides a global view
of the project as well.  However, given the number of contributors who
complain of cognitive overload, it's arguable that a standalone branch
structure with some kind of auxiliary tool for browsing multiple
branches simultaneously would be be a better fit for the common
workflow.

Of course in Bazaar, one can surely implement a shared repo viewer or
something like that which would have similar "overview" functionality.
Note that a Bazaar shared repo in fact contains colocated branches;
it's just that core Bazaar doesn't provide a way to work with them
(yet).

 > The whole null-merge requirement drives me crazy, but I suppose
 > that's all just a result of the specific choices made for the
 > Python project.  It's the only large hg repo I interact with on a
 > daily basis, so my world-view of hg is admittedly skewed by it.

In how many large repos of *any* VCS do you interact with as many as 6
active "mainline" branches at the same time?  I'm pretty sure that if
you short circuit step (2) in the workflow above, any DAG-based VCS
will need a null merge.  OTOH, with step (2) there will be a redundant
merge into the base branch for the throwaway branch.  ("Redundant" in
the sense that you could have done the work in that base branch.)

I suppose a Sufficiently Smart VCS could handle omnidirectional
merging, i.e., forward and back from any branch you happen to be
working in, but I doubt even Bazaar or Darcs can do that yet.


Footnotes: 
[1]  Ie, what I said about "mostly useless" is from the point of view
of a project full of developers who dislike coloc.  Personally, in the
workflows I find natural, a coloc structure makes a huge amount of sense.
However, AFAIK it should be easy to pull down a bunch of branches from
python.org and make a coloc repo of them for oneself, and that should
only need to be done once.