Recipes vs. Looms

[Andrew Bennetts]

Michael Hudson wrote:
> James Westby wrote:
[...]
> > including operations that
> > add and delete threads. This is crucial to building a
> > packaging system on top of them.
> 
> It has to be said that I have never confidently been able to predict
> what doing "bzr push" in a loom would do.  This falls into the "polish
> required" category I guess.

There is a bit of a transparency problem with looms when compared with
recipes.  With a recipe all the data about the recipe is there in a single,
flat text file.  With a loom it's a bit harder to see what precisely it's
recorded (developers may know precisely how a 'thread' represented
internally, but users don't).  It's harder to see the history of the loom
state (what 'bzr record' does).  It's not trivial to see the precise
ancestry relations of all the threads (a sufficiently smart 'bzr qlog' or
'bzr viz' could help here), but the ancestry matters to some extent when
doing 'bzr up-thread'.  Another example is how can I know if a loom here has
precisely the same state as a loom somewhere else (and how can I know if the
differences matter)?

Ideally looms would be fully intuitive and users won't care about this level
of detail.  But abstractions tend to leak, especially when a tool still has
many rough edges.  So as much I like looms, I think recipes currently have a
bit of an advantage in terms of explainability and predictability. 

-Andrew.