On Tue Dec 15 03:19:34 +0000 2009 Andrew Bennetts wrote: > 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.
I think these are great comments, thanks. One thing I have considered is providing a way to edit a loom via a recipe description of it. You could produce the flat text file version as required, then have a command that makes the loom like an edited version. I'm not sure this would be either helpful of useful though. Thanks, James -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
