Recipes vs. Looms vs. pipelines
barry at canonical.com
Thu Dec 17 16:53:20 GMT 2009
On Dec 16, 2009, at 3:15 PM, Aaron Bentley wrote:
>> 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
I know. I said it was difficult to explain! ;)
I think Vincent came the closest to describing why the loom approach feels better than the non-loom (leaving out pipelines for the moment). With the loom approach, I can much better organize my thoughts and tasks. I have the thing I started with unchanged at the bottom. I have my initial work next. I have the results of my review next. Then I have any additional work I had to do to actually land the thing. It's all nice and neat and I can very easily find exactly the changes between any two of those tasks. 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.
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.
> Also, note that you don't need "../devel" in most cases.
Yep, that was mostly just for example purposes.
>> 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.
Yep, see above. 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, ignore what other people changed unless it affects my change, and help me organize my changes into tasks.
>> 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. 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. I do this when my changes have landed.
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. This is a bit ugly, but it's manageable because I export all my looms to a separate parent directory that I can easily delete once I'm done with it, and it's very easy for me to identify which loom directory the export is associated with (by name). So while I'm not crazy about this step, it's not a feature killer for me.
More information about the ubuntu-distributed-devel