Bazaar Mercurial Plugin to access BitBucket

[Barry Warsaw]

On Oct 23, 2011, at 02:03 AM, Stephen J. Turnbull wrote:

>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!

Sorry, you've lost me with that analogy. ;)

>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.

Perhaps.  What I don't particularly like about colo branches is the "hidden"
nature of all those other branches.  If I were to embrace the
one-directory-many-branches workflow that colo exposes, then I'd be constantly
wondering which branch I'm actually making changes on.  Since I'm old and
forgetful, `hg branch` would probably be my every other command.  I know this
because occasionally I do work in the direct clone directory and I'm never
really certain which branch I'm working on.

One-branch-per-directory is completely obvious because it's right there in my
shell prompt.  This is where you suggest I add `hg branch` to my shell
prompt. <wink>

The other thing I like about one-branch-per-directory is that they're very
cheap.  I might have three different stabs at a fix going on, none of which
I'm completely happy with yet.  But who cares? because it's easy to just
create a new local branch to experiment with.  Later, I'll either just delete
the directory, or commit and merge to the trunk.

The other troublesome bit is that when I grab a clone, I get *everything* even
for branches I might not care about.

>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.

Right, and Python disallows (by policy) merges from 2.x to 3.x.

>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>)

The problem in practice is that merges between the separate branch directories
is much more complicated.  I don't remember all the details, but IIRC whereas
in Bazaar I'd just do a `bzr merge ../2.7` in Mercurial I have to pull the
changes over and *then* merge, of course making sure that I'm switched to the
correct branch before I do that.  Seems awkward and error prone to me.

>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.

I guess I'm less concerned with that global view from one single directory,
since I'm just as comfortable keeping a couple of directories updated and then
just using normal filesystem level tools (e.g. editors, less, grep, etc.) to
find out what I need to know about the other branches.  In fact,
separate-directories-per-branch is actually more friendly for normal file
system tools than colo-branches.

>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).

Right, and that seems like the perfect balance to me.  But I'm just as willing
to admit that it's that way because I have 4 years of daily bzr experience
under my belt and have found that its natural workflows work best for me.

> > 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?

The closest I come to this is working on a packaging branch for Ubuntu.
There, I might have branches representing two or three Ubuntu versions of the
package, and maybe two Debian versions of the package.  Let's say I'm
comparing changelog or rules files.  The fact that I can bring up all 5
versions of those in Emacs from separate branch directories (in a shared
repo), or just `head oneiric/debian/changelog` without having to do any kind
of branch switching is *priceless*.  I'll happily pay the modest cost of an
occasional `bzr pull` before starting to work for that very important
convenience.

>[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.

I think that's the key for me.  colo-branches is the way Mercurial tends to be
most comfortable in.  Bazaar prefers one-branch-per-directory.  With all the
caveats that come with those last two statements, Bazaar's model feels much
more natural to me.  It's also true that everyone works differently, so I feel
strongly that the tools should adapt to the person, not the other way around.
We have choices of editors for that very reason, as you know. :) What I like
about Bazaar's philosophy (if it doesn't always come through in practice) is
that it tends to enable and support different ways to work, adapting to how
you like to work.

That comes at the price of complexity, which is why things like tutorials have
to be opinionated and focused without introducing all those choices at first.
Fortunately, the basic stuff is easy to get a handle on and once you've
adapted the tool to your preferences, it stays mostly out of your face.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20111024/1061500d/attachment.pgp>