Recipes vs. Looms vs. pipelines

[Aaron Bentley]

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

Barry Warsaw wrote:
> On Dec 17, 2009, at 01:26 PM, Aaron Bentley wrote:
> 
>>> 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.
> 
> What happens if I update my trunk?

Nothing bad, IME.

> In the loom-based approach, my bottom
> thread won't be updated until I explicitly take that step.  In the branch
> based approach, all my branches will "see" the update.

"See" in what sense?  If you mean that they will diff against the wrong
version, they won't if you use -r submit: or -r ancestor:

>>> 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.
> 
> Right, but it's the difference between thinking about it like: "oh, I'm just
> tracking trunk changes" to "I'm weaving in the trunk changes with my current
> work".  I dunno, maybe I need to change my mental model, but to me there's a
> very distinct difference.

I think of "pull" as the "tracking" command and "merge" as the "weaving
into my work" command.  It almost sounds like you're thinking of the
pull into trunk as "merging trunk".  Is that accurate?

>> 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/
> 
> Thanks, that helps a lot.  I will definitely give this a shot for the next
> branch I'm working on.

Cool.  Note that the checkout command should actually be "bzr checkout
- --lightweight bar".  (I have "checkout" aliased to "checkout
- --lightweight --hardlink".)

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

iEYEARECAAYFAksroukACgkQ0F+nu1YWqI3hVgCfTH+c6mPS5956vzj4OdRqfGX2
788An1cXGPmGyYqx0MuYAPi9FWoDZIaR
=idZj
-----END PGP SIGNATURE-----