Bazaar Mercurial Plugin to access BitBucket

[Stephen J. Turnbull]

Barry Warsaw writes:
 > On Oct 25, 2011, at 04:26 PM, Stephen J. Turnbull wrote:

 > 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.
 > 
 > I'm still not quite sure how colo branches make that visible,

Well, gitk and friends help a lot in making relationships visible.
Since the kernel workflow is based on "rebase", the DAG Linus sees
will be very bushy (unlike the one you see for CPython at
hg.python.org).  That kind of information is often useful to me in
planning.  Bushy trees generally mean a period of minor annoyances to
come.  Long parallel limbs mean a painful merge to come.

 > If I saw feature branches in that repo, how would I know what's
 > waiting to be merged?

You wouldn't.  But Linus does, because he has explicitly pulled the
branches he wants to work on into his repo.

I don't know how he manages the metadata (milestones and status); it's
not part of git.  I suppose it's generally email-based.

Linus is (was?) brutally honest about what git is -- it's a content
tracker.  It is not a full-blown management product, "SCM" is a
misnomer IMHO.

[[ Clarification:

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

That's what I meant by "what I think you use looms for". ]]

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

I assure you, it doesn't, because of the requirement for copying the
working tree.  You really need coloc to make branching go fast there.
Shared repos are definitely a big win, though, since they reduce
history copying to nearly nil.

 > 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 would have to agree, because the bzr-based workflow Karl Fogel
recommended for Emacs has the same feature of a primary clone that all
the pushes-to-public go through.  On the other hand, some people (eg,
Richard Stallman) seem to just use lightweight checkouts.

But Emacs has only one mainline.  Again, I have to think that the
synchronization of multiple mainlines has a lot to do with the need to
merge to a full (all branches) coloc repo before pushing to Python.

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

Well, git's fast-import format is pretty close.  There was an all-DVCS
summit where developers from each got together to somewhat standardize
that format.

But I don't think you're going to see convergence in the disk
formats.  Bazaar prides itself on accurate representation of what the
user did, as you see in the thread by Martin and Ben.  You also see
there that Martin doesn't really care about corner cases like empty
directories.

On the other hand, both do pride themselves on accurate powerful
merging algorithms.  I haven't actually talked to the git developers
about it, but I tend to doubt that they really care all that much
about having the *best* merge algorithm.  Rather, git is about
providing the most powerful tool for (1) helping humans to merge
effectively, and (2) presenting a series of changes to those who are
responsible for integrating branches.  So git focuses on (1)
performance and (2) DAG editing capability more than on having the
best merge algorithms.

I doubt a single on-disk format will satisfy all three.

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

In general, I don't think that's going to be feasible.  Interchange of
the DAGs and file content, yes.  However, since Bazaar seems to record
a superset of the metadata that anybody thinks is necessary, you're
probably going to be able to interact with anybody's VCS using bzr
(eventually, and of course bzr-git and bzr-svn are quite advanced
already).  On the other hand, you're going to have to accept
limitations of other's tools when using your "native" bzr
repositories.