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