Bazaar Mercurial Plugin to access BitBucket

[Stephen J. Turnbull]

Barry Warsaw writes:
 > On Oct 23, 2011, at 02:03 AM, Stephen J. Turnbull wrote:
 > >Barry Warsaw writes:

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

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.

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

 > >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, and for the kinds of things
you use looms for (do you have trouble remembering which thread you're
in?)  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.

You might say that sounds like "a man with a hammer," and I'd agree to
some extent.  But so far, most of the things that looked like nails
turned out to *be* nails, and when they weren't, recovery is very easy
(just clone a new workspace).  Improving my workflows is easy and
constant, because they're based on a few simple concepts.  I am *much*
more likely to use the VCS this way, rather than avoid involving it.
This "git jones" is different from most tools (where getting too
wrapped up in the tools generally hinders productivity), because as a
side effect the addiction to VCS produces a richer history, which I
often find useful.

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

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

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

git init
git pull /some/interesting/branch [more branches ...]
git checkout /most/interesting/branch

That's for git.  I don't know if the nomenclature above works on
Mercurial named branches or bzr coloc branches, but some similar
commands surely will.

 > The problem in practice [with Python's repo structure based on hg
 > named branches] 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,

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

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

 > 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.  Sounds reasonable to me.  I'm just trying
to explain some of the reasons why some people prefer colocation.

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

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

Dunno about hg, but in git you can have all that at zero cost, maybe
slight negative cost, vs. bzr.  Just use --local when cloning.  In hg
it might cost some disk space if object storage can't be shared.  (hg
does use hardlinks when cloning, but I don't know how quickly new
storage is needed as the branches diverge.  At worst I suppose each
file's history storage gets duplicated when that file diverges.)

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

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

Sure.  When I'm working *in* a branch, I don't want it shifting around
on me.  I just don't perceive any loss in "locality" because of
colocated branches (the way I use them in git), and the additional
capabilities that come with coloc are often useful 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. :)

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

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.