Looms and Pipelines (was Re: Git mirrors)

[Barry Warsaw]

On Oct 17, 2011, at 08:57 PM, Stephen J. Turnbull wrote:

>It is most definitely not habit in my case.  It's lack of colocated
>branches, and lack of technical documentation for pipelines and looms.
>I need technical documentation because I have a very clear idea of
>what workflows I want to implement, and the use cases and tutorials
>published for those tools don't match my workflow.  Sadly it seems
>pipelines can't do it (they're different from Mercurial queues) and
>looms I've never figured out.

I personally dislike colocated branches, and it's one of the things that
drives me crazy about using Python's Mercurial repo.  I always end up
splitting it into one-branch-per-directory, but twisting the tool's basic
workflow model into my own comfortable workflow causes problems (e.g. a recent
commit of mine where I somehow managed to double-merge a branch).

That aside, I recognize that some people really like colocated branches, so
I'm glad bzr is going to have support for them in the next release.

Looms and pipelines provide different use cases, IMO.  Both are useful for
managing a "stack" of related but separable changes.  Imagine you need to make
a change to your database, your model, and your UI.  These different layers
can be represented in that stack of branches.  You start by making a change in
the database and commit those, then move up to make a related change in your
model, and commit those.  When you get to your UI changes, you realize that
your database is missing something critical, so you pop back down to that
layer and make the change.  Then using pipelines/looms, you jump back up the
stack, and let bzr automatically merge your database layer changes to every
branch up the stack.

Why manage these as a stack of related changes, i.e. branches?  For one thing,
it lets you have smaller, more manageable, more reviewable changes.  Maybe you
want to share your database changes without sharing your UI changes.  Maybe
someone else beat you to committing the model changes, but your other changes
are still relevant.  Maybe someone changed the public API between the model
and UI and you'd like to merge their changes in at the appropriate layer, but
keep them separate from your own changes.  Maybe you just want to look at a
diff of the model changes and ignore everything above and below.  Looms and
pipelines help with all the nasty bookkeeping that you'd normally be forced to
do to keep all the relationships together.

I'd say that the primary difference between pipelines and looms is that the
latter version controls those relationships.  I.e. the metadata that describes
those relationships between your stacked branches is under bzr.  That means
you can share, push, publish, and pull a loom as one unit, maintaining those
relationships.  Yes, you can also separate your stacked branches (called
"threads" in loom terminology), into completely independent branches.

Pipelines on the other hand, don't version control that metadata, but the
advantage is that every branch in a pipeline is a completely normal Bazaar
branch, so there's not much special about them.  OTOH, if you're going to pull
a loom from me, you need to have the plugin installed locally because threads
*are* special.

If you're familiar with the Debian quilt system, there is a *lot* of
similarity between looms/pipeline and quilt.  So much in fact, that the bzr
team is considering using looms/pipelines as a mapping to quilts for Ubuntu's
source branches on Launchpad.

The major disadvantage of both looms and pipelines is that they are currently
implemented as plugins, and while they are kept up-to-date and compatible with
new bzr releases, I'm hopeful that at some point the loom feature (which I
prefer) will be brought into core bzr.

Note too that loom/pipeline are completely optional for any particular branch
you work on.  You can still install the plugins and use vanilla bzr, since you
need to initialize a branch to use (e.g.) looms explicitly.

Cheers,
-Barry

signature.asc
Description: PGP signature