Recipes vs. Looms vs. pipelines

[Aaron Bentley]

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

Barry Warsaw wrote:
> On Dec 16, 2009, at 3:15 PM, Aaron Bentley wrote:
> It's all nice and neat and I can very easily find
> exactly the changes between any two of those tasks.

So, to have a fair comparison with a branch-based approach, let's
consider a loom with two threads, one the base thread and one your
actual development.

In the loom case, you do "bzr diff -r thread:" to view the difference.
In the branch case, you do "bzr diff -r submit:" to view the difference.

I think the two are equally easy.

> Maybe I want to
> decide whether the work I had to do to land the code needs extra
> review.  With a loom, there's no problem finding this.  With a
> non-loom it's much more difficult especially if you've got several
> trunk merges interspersed.

Sure, I can see the virtue of a stack-based approach if you want to view
the work separately.  But this doesn't help me understand why you would
want trunk as the base thread.

I have thought about implementing a diff that ignores changes introduced
by merges.  It's just a matter of tuits.

> Updating the bottom thread and up-threading --auto falls into this.
> It's usually a trivial, inconsequential afterthought.  Most changes
> on trunk don't affect my work, so I don't care about them.  I'm
> merging trunk to be diligent.  The fact that I can mentally segregate
> that to the bottom thread helps me ignore it completely in the common
> case, even if the end result is the same.

I don't see how this lets you mentally segregate it to the bottom
thread.  up-thread --auto affects all threads.

> Supporting the type of workflow I describe above in
> core bzr would be a win.  It's all about fitting the model I have for
> developing software, which really boils down to: tell me what I
> changed
As above, I think the branch-base workflow does tell you what you changed.

>, ignore what other people changed unless it affects my
> change

- -r submit: does this

> and help me organize my changes into tasks.

At that point, you want a stack, but it doesn't need to have a trunk thread.

>>> 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.
> 
> But it feels heavyweight because my branches are right there in the
> directory containing my working tree.

If bzr-pipeline used heavyweight checkouts, you would still need to have
branches somewhere else.  It would just mean that the tree would have a
copy of whatever branch you were currently working on.

> I like this because there are
> no extra directories to worry about, and I can delete the loom
> directory in one rm-rf and be completely done with it.

This is actually co-location of trees with their branches.  You can
accomplish this with lightweight checkouts by putting the branch inside
the .bzr directory of the branch.

$ bzr init foo
Created a standalone tree (format: 2a)

$ bzr checkout foo bar
$ mkdir bar/.bzr/branches
$ mv foo bar/.bzr/branches/
$ cd bar
$ bzr switch --force .bzr/branches/foo
Tree is up to date at revision 0.
Switched to branch: /home/abentley/sandbox/bar/.bzr/branches/foo/

Obviously, this is more steps than it should be, but it would be easy to
turn into a reconfigure operation.

> I should note thought that there's a wart in looms related to this:
> export-loom.  If I have to share my loom threads with others (e.g. a
> merge proposal), I have to export it into separate branches.

You can also use import-loom to convert it to a pipeline, which will
preserve ordering information, so it can be used by lp-submit.

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

iEYEARECAAYFAksqd7kACgkQ0F+nu1YWqI0otQCcCVk0ODm2GSmQKaehK/FJE5Ib
APsAn2YerKa4onpSqHhLjLlxcWhyBvHX
=lyKu
-----END PGP SIGNATURE-----