Recipes vs. Looms vs. pipelines
Vincent Ladeuil
v.ladeuil+lp at free.fr
Thu Dec 17 15:33:39 GMT 2009
>>>>> "jam" == John Arbash Meinel <john at arbash-meinel.com> writes:
jam> Vincent Ladeuil wrote:
>>>>>>> "barry" == Barry Warsaw <barry at canonical.com> writes:
>>
>> <snip/>
>>
barry> loom non-loom
barry> ---- --------
barry> bzr down-thread rocketfuel bzr merge ../devel
barry> bzr pull bzr commit -m'Merge rocketfuel'
barry> bzr up-thread --auto
>>
>> Nice, I never put words on that but I share the feeling. In my
>> mental model the "loom way" is: let's restart what I'm doing
>> based on today's trunk, whereas the "non-loom" way is: let's see
>> what happen if I bring trunk into my branch.
>>
>> Or said otherwise: one inject the new trunk from the bottom when
>> the other inject it from the top.
>>
>> Of course the resulting tree is the same, but since they produce
>> different histories, the resulting branches tend to behave a bit
>> differently too when you start landing part of your work on the
>> trunk and that you re-inject the trunk
>>
>> Vincent
>>
jam> Actually, those produce the exact same history.
No.
jam> What you are describing "verbally" sounds a lot more
jam> like the rebase workflow. Where you bring in trunk at
jam> the 'bottom' of your changes and put them all on top.
Yes, except for the history-lost part of rebase.
jam> I guess if you have more than 1 feature thread the
jam> history might be different.
No. A base thread for trunk were I can pull and feature thread on
top is enough.
In one case I *pull* trunk in the base thread while in the other
I *merge* trunk in the top thread. That's enough to build
different histories.
Vincent
More information about the ubuntu-distributed-devel
mailing list