Bazaar Mercurial Plugin to access BitBucket

[Barry Warsaw]

On Oct 25, 2011, at 04:26 PM, Stephen J. Turnbull wrote:

>How about this explanation: Linus may be a coding genius, but those
>are a dime a dozen.  What changed the world is that he turned out to
>be a project management genius, and his productivity is measured in
>merged KBranches, not new-or-changed KLOC.  He was wearing his project
>management hat when he designed git.

Okay, I get what you're saying here.

>Coloc branches make maximum sense when you're looking at the program
>from "outside" (thinking about which features to merge) rather than
>"inside" (thinking about how to implement a feature).

Perhaps.  I certainly would expect that a dvcs designed from the perspective
of the kernel's uber-papa would reflect the project management needs and
workflows evident in that project.  And based just on evidence, he must have
hit enough key points right for it to work with other projects as well.

I'm still not quite sure how colo branches make that visible, unless there are
some magic tricks to recording and visualizing the relationships of the
colocated branches in a repo.  Just having a mishmash of heads wouldn't do it
for me.  E.g. `hg heads` in the Python repo lists a bunch of things but tells
me really nothing about the relationship between them.  (Admittedly, I could
be badly generalizing from an inappropriate example.)

If I saw feature branches in that repo, how would I know what's waiting to be
merged?  How would I know what official heads those feature branches should be
merged into?  How would I know what the state of the feature branches are
(e.g. tested, reviewed, blessed, merged, abandoned, etc.)?  Or is all that
extra metadata not stored in the repo, or is it stored in a way that other
git/hg tools will display?

For me, just the mere presence of the other branches doesn't tell me much,
although I can see where it would be useful to be able to slurp them all over
in one command in one directory.

FWIW, while Bazaar is completely useful to me as a standalone tool, it is true
that I use it mostly in conjunction with Launchpad, which *does* have lots of
facilities for telling me the state and relationship between branches of my
projects.  So either the LP website or its command line access gives me
(almost) everything I need to know about what is happening with contributions
and outstanding work for my projects.

I think this is analogous to git and hg fans being so enamored of github and
bitbucket as essential tools for increasing their productivity.

> > >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.
>
>"Embracing" is one thing; monomania is another.  Eg, when using git, I
>never wonder.  All my active branches (those beyond my ability to keep
>them in short-term memory) have their own workspaces.  I explicitly
>use coloc branches for detours that I know wil be merged (somewhere)
>within the span of my short-term memory,

So I think that mirrors the way I work, minus the colo branches.  IOW, long
term work, whether it be a feature branch that's taking a while, or a merge of
someone else's branch that needs some additional work, all happen in separate
workspaces, i.e. one-branch-per-directory.

>and for the kinds of things you use looms for (do you have trouble
>remembering which thread you're in?)

Actually, I rarely use looms for this.  Where I use looms is where I'm working
on a multi-layered complex feature, or sometimes when I'm merging in someone
else's branch that doesn't apply cleaning, or requires some lower level
refactoring before its acceptable for merging.  Looms is used when I need that
layer separation for my own sanity to manage the complexity of the immediate
task.

And yes, I do sometimes forget which thread I'm in. :)  It's a little more
obvious in that case though because looms are stacked, so it's clear that if I
was expecting to see a model change but don't, I'm probably in the lower
leveled database thread.  Still:

bzr alias looms="show-loom"

is my friend there.

>And of course as a technical matter git requires colocated branches for
>diff'ing and merge'ing, but that's an occasional annoyance to me, not a
>feature I explicitly use.

Doesn't hg also require that.  I could be totally wrong here, but I seem to
remember that I could not hg diff between clone-per-directory.

> > 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>
>
>Indeed I do.  But I don't claim it's a fix, only a workaround for the
>structure that Python imposed on you.

Right.  It's a structure I mostly manage by having one directory-per-branch
nailed to the major version's head.  Then I have a clone of cpython, which is
where I'll `hg pull -u` when starting new work.  If I have to hack on a
particular version, I cd to that directory, hg pull -u it in and start.  Where
things get icky is the need to go back to the cpython clone, pull in the
changes and then merge them.  It would be rather nice to be able to "just
merge" without the extra pull, but that habit gets quickly broken and fairly
easily worked around when its failure reminds me that hg doesn't work that
way.

> > 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.
>
>Coloc is cheaper yet, though (zero copying, including the workspace),
>and since bzr has neither coloc (now it does, but when my preferences
>were formed it didn't) nor nested branches (hg: subrepos, git:
>submodules), I find branching painfully slow with something the size
>of XEmacs, let alone the Linux kernel or OOo.

I personally believe that using a Bazaar shared repo is the only way to go.
OTOH, that might not even help with a project the size of the kernel or OOo.

>[extensions]
>hgext.fetch =
>
>and use the "hg fetch" command, is what you want, I believe.  (My
>workflows don't need it; I prefer "hg pull -u".)

Nice, I'll have to try that.

> > of course making sure that I'm switched to the correct branch
> > before I do that.  Seems awkward and error prone to me.
>
>Are you really that short on disc space that you can't afford a repo
>per active branch?  (If you prefer, "are your projects that big ...".)
>AFAICS, for Python you need four (three for the three active mainlines
>and only if you're a security person, and about one more for your
>current personal project).  What's that, a total of 500MB?  Of which
>most is source code and build products, not copies of history.

It's definitely not a disk space, or even network bandwith issue (I have
plenty of both), and I do have one clone per active branch.  It's just that
merging everything up into the primary clone (i.e. the one cloned from
hg.python.org) for pushing when all is said and done, is a pain.  I'm
perfectly willing to accept that that's because of the peculiar way that
Python organizes its repo and the policies it imposes on it, rather than some
inherent Mercurial limitations or biases.

> > 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.
>
>Which just goes to show that you care more about project content than
>global project structure.

Hmm, I'm not so sure I'd go that far.  I'm still struggling to see how colo
helps me with that.  I could just be one of those things you don't get until
you get it, kind of like how it's nice to have an IRC client in your text
editor. :)

>Sounds reasonable to me.  I'm just trying to explain some of the reasons why
>some people prefer colocation.

Which I appreciate!

> > In fact, separate-directories-per-branch is actually more friendly
> > for normal file system tools than colo-branches.
>
>Assuming you have the required branch, as you admit. ;-)  (Your point
>being that it's a momentary inconvenience, and you'll probably reuse
>the newly pulled branch.)

I certainly reuse the shared repo, which usually makes fetching the required
branch quick and easy, since invariably, you'll already have most of the new
branch's history already.

> > I think that's the key for me.  colo-branches is the way Mercurial
> > tends to be most comfortable in.
>
>Actually, if you're used to git, Mercurial named branches are awkward.
>And since XEmacs banned them, we have not missed them one bit in daily
>usage.  Your situation is simply that your project uses them so you
>can't avoid them.

Right.

> > 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. :)
>
>Unlike editors and airlines, choice of VCS comes at a high price if
>you choose one different from your coworkers, starting with the need
>to remember multiple nomenclatures.  (I find Bazaar's to be rather
>unintuitive; for example "pull" and "push" should really be reserved
>for arbitrary subsets of revisions and their ancestors; use "clone,"
>"mirror," or "sync" for synchronizing at the branch or repo level.)

What I'd *really* like to see is convergence on the wire and disk formats, and
let innovation occur in the ui and gui tools.  I know that's not feasible now
(I'm vaguely aware that Bazaar is the only dvcs that version controls certain
metadata like revision signatures), but I don't see why it couldn't be
possible.  That world gets closer to making your choice of dvcs a personal
preference that doesn't impose an impediment to others collaborating with you,
which I think is the ultimate purpose of a dvcs.

>I really don't see why Mercurial has to be a drag on your work in
>Python; it certainly is not due to the *fact* that it supports
>colocated branches.  I have to think that you're just using
>inefficient/unreliable workflows for the tool in the context of
>Python.  While you've done more than your share in improving Python's
>VCS system (even if your recommendation eventually came in second),
>and so I can't in justice say you should *work* on your workflow, I
>hope you'll take every opportunity to ask Mercurial experts to suggest
>improvements.

Well, as I say, I've adapted to the choices made in the Python project, so
I've lost that beginner's mind.  It really doesn't slow me down much until and
unless it breaks.  That's not the same as being comfortable or loving it
though.

-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/20111025/fa9548f3/attachment-0001.pgp>