Recipes vs. Looms

[James Westby]

On Mon Dec 14 22:47:24 +0000 2009 John Arbash Meinel wrote:
> >> I think the two systems do have a significant overlap. Recipes are
> >> slightly easier to share, as their state is fairly well defined and
> >> small in scope. Looms *do* have a shareable state, but it isn't quite as
> >> simple as emailing a text file to someone. (Note, though, that if Merge
> >> directives are taught about loom information, you could potentially send
> >> a MD to someone which would build out the loom state.)
> > 
> > The issue with *just* emailing someone the recipe file is that currently
> > they will end up with a different revision history in the final tree. Perhaps
> > this is a mistake, but it means that just the text file isn't currently
> > good enough for collaboration where this matters.
> > 
> 
> How so? I thought recipes were meant to build the working tree, and not
> actually commit any data. Obviously I may be mistaken in what recipes
> actually include.

Currently it will do some commits.

You can merge multiple branches, and if you don't commit then the latter
ones fail with "uncommitted changes." Forcing that then leads to spurious
conflicts as the latter merges don't take in to account the ancestry they
share with the other parents of the working tree.

This is possibly a bug, or a mistake on my part, but that's how it currently
works.

It doesn't fully commit and give you a single branch and unmodified tree
in all cases though, it just does enough to merge sensibly, so I still consider
it to be mainly a tree thing.

> I think it would be a reasonable compatibility thing to be able to
> export the first N threads of your loom into a debian + patches tree. It
> is quite unclear to me whether this should be a thread above or below
> the actual threads that produced these changes. (I would probably say
> above, mostly because I think 'debian/' should be introduced above the
> content changes...)

I agree. Sort of.

The way I see it working is that you don't think about debian/patches at
all. You have threads that make the changes, then the packaging on top.

When you build a source package it diffs each thread with the one
below, puts them as diffs in debian/patches, and then modifies the
packaging. You can then build this to a v3 source format that the
tools know how to work with.

I think loom would have other commands to do similar things in general
(diff -rthread:, export-loom etc.)

> bzr create-thread --based-on X
> 
> And the default of --based-on is the current thread. Presumably all
> threads would be --based-on at least 'upstream'. I guess it would also
> allow being supplied multiple times for the thread that brings together
> the previous threads.
> 
> I think the bigger issue is that 'bzr up-thread' gets a lot more
> complex. Given that up-thread to the bring-together thread potentially
> issues several merge + commit statements. (At least several merges, we
> could octopus merge it if we wanted.)
> 
> At least it would have all the information of what branches it would
> need to merge in its DAG info.
> 
> You would probably need to add the ability to add and break links. "bzr
> thread-dependencies, bzr remove-thread-dependency, bzr
> add-thread-dependency, etc.)
> 
> It doesn't seem terrible. Though there is always the "one more layer of
> abstraction" that ends up making something hard to work with.

I think you have summed it up quite well. Again, I'm not against this,
but that UI doesn't seem pleasant to me, and we should perhaps look at
other ways of solving the problem of merging threads out of order.

Thanks,

James