[rfc] bzr-colo into core

Stephen J. Turnbull stephen at xemacs.org
Wed Mar 23 03:02:10 UTC 2011


Barry Warsaw writes:

 > I had a similar conversation with folks at Pycon.  As tempting as
 > it is to reduce built-time, I don't quite trust switching branches
 > in place to cause the right combination of recompiles.  I was not
 > alone in my unease. ;)

This doesn't bother me at all, as long as the directory timestamp of
the workspace files is when they are checked out, not when they are
checked in.  Thus, if you change branches, all changed files will show
up as changed, and be recompiled.

What's the problem?

I've never seen a problem with underrecompilation in git.  In fact,
excess recompilation is the big problem.  Ie, I switch branches to
examine an alternative or stash a commit in the appropriate thematic
branch, then switch back.  Voila, I have changed no content, but
files' timestamps are updated!

 > I completely agree.  This is one of the most jarring adjustments
 > for me with the switch to Mercurial for CPython.  I'm not really
 > sure why I'd want one repo to contain multiple branches,

Well, you can't do a merge unless it does. :-)  What you mean is you
don't know why you would want a workspace to be associated in the UI
with multiple branches.  The answer is, you want it for the same
reasons you want to use mq, pipelines, or looms, except you want more
persistence of history than you get from mq (and I would assume you
get from pipelines and looms).

It seems to me that use of Mercurial named branches in CPython was a
mistake, because of the discontinuity at fork and merge nodes.  I
think that "branch" has become identified with the concept "line of
development" (aka LOD, ie, a branch starts from an empty source tree
and is continuous all the way to its tip), and the discontinuity of
soi-disant "named branches" is jarring and inconvenient in many ways.
And the reason above (basically, stashing experimental LODs) doesn't
apply to public repos.

 > I can't imagine that would go away.  I see it as a huge win for Bazaar's
 > model.  Still, bringing bzr-colo into the core gives folks who prefer it the
 > other way 'round a choice, and that *too* is one of the big wins for
 > Bazaar. :)

Yeah, I might actually start to use bzr in anger, instead of getting
angry when I have to use it. ;-)



More information about the bazaar mailing list