Recipes vs. Looms vs. pipelines

Aaron Bentley aaron at canonical.com
Wed Dec 16 20:15:49 GMT 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Barry Warsaw wrote:
> On Dec 16, 2009, at 02:20 PM, Aaron Bentley wrote:
> 
>> Barry Warsaw wrote:
>>> When I'm developing bug fix or feature branches, I
>>> always like to have the devel branch as the bottom thread in my loom.  Note
>>> too though that I want control over when I update the bottom thread
>>> independently of when I update the devel branch.
>> What advantages does that gives you?  Do you find you miss those when
>> working on non-loom branches?
> 
> It allows me to very easily merge changes that are happening all the time on
> devel with my feature or bug fix, but on my schedule.

I don't understand what the advantage of a loom over a branch is.  The
merge should be just as easy with a branch.  A branch should also allow
you to do it on your schedule.

> I might update the
> Launchpad devel branch while I'm in the middle of my bug fix, for various
> reasons (e.g. I'm working on more than one branch at a time, I want to see how
> "pristine" trunk works, etc.).  When my branch is ready for review, I want to
> pull in devel's updates and merge them up my stack.

Again, I don't understand how this is any different with a branch.

> I do miss this when working on non-loom branches, but of course a 'bzr merge
> ../devel' is the moral equivalent.  It doesn't /feel/ the same though:
> 
> loom                            non-loom
> ----                            --------
> bzr down-thread rocketfuel      bzr merge ../devel
> bzr pull                        bzr commit -m'Merge rocketfuel'
> bzr up-thread --auto

I don't understand.  The non-loom form is faster and requires fewer
commands.  Why do you prefer the loom form?

The pipeline version is even fewer commands:

bzr pump --from-submit

Also, note that you don't need "../devel" in most cases.

>>> This is something that feels more natural to me in looms than in pipelines.
>> bzr-pipeline is meant to allow you to use your normal development habits
>> as much as possible.  In fact, a normal branch is also a pipeline with a
>> single pipe.  When you are normally working on a normal branch, the lack
>> of an upstream pipe should feel perfectly natural, so why does it feel
>> less natural when you add a second pipe?
> 
> See above for the specific answer: normal branches in fact do not feel as
> natural to me

Okay, so just to telegraph this, you actually feel there are
deficiencies with a branch-based workflow.  This is something that we
should try to fix in core bzr, and if we do, that should also fix pipelines.

> One of the other things that just rubs me wrong about pipelines is that they
> require lightweight checkouts.  I can't explain it, but lightweight checkouts
> have just never felt "right" to me.

A loom essentially has a lightweight checkout-- it's just implemented
differently.  It is a working tree that you use "bzr switch" to switch
between different named heads.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkspP/IACgkQ0F+nu1YWqI2HgwCdEWc5NOPfFBlCAHNdKJb1IlpM
hL4An3Z7zpe4XBFKTxeZZfFOuwlScuVX
=/Vx0
-----END PGP SIGNATURE-----



More information about the ubuntu-distributed-devel mailing list