Recipes vs. Looms vs. pipelines
Aaron Bentley
aaron at canonical.com
Thu Dec 17 18:26:04 GMT 2009
-----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-----
More information about the ubuntu-distributed-devel
mailing list