Supply a 'check thread is ok' hook.

> When updating something at the bottom of the stack it
> is boring to do up-thread; commit repeatedly, and the user
> may just want the same message for all.

> It would be possible to have a way to do them all at
> once using the same message for each, stopping if there
> is a conflict to resolve.
>
> However, I realise this goes against bzr's philosophy
> on merges, and so may be rejected.

given that the loom itself provides a meta-status, you can revert the
entire loom to undo all the merges done to threads since the last
'record', I don't think that the bzr philosophy is violated; we're just
moving up a level. However, I think we should at minimum provide a hook
to test each thread as the merge progesses.

For instance, one could have in branch.conf
thread_test = 'make check'

then 'bzr switch upstream && bzr pull && bzr up-thread -a -m "Merging
upstream."' will run 'make check' as it goes up each thread, stopping at
the first error but otherwise committing with 'Merging upstream.'

 status triaged
 importance high

-Rob

--
GPG key available at: <http://www.robertcollins.net/keys.txt>.
>

On Sun, 2008-02-24 at 21:22 +0000, Robert Collins wrote:
> given that the loom itself provides a meta-status, you can revert the
> entire loom to undo all the merges done to threads since the last
> 'record', I don't think that the bzr philosophy is violated; we're just
> moving up a level. However, I think we should at minimum provide a hook
> to test each thread as the merge progesses.
>
> For instance, one could have in branch.conf
> thread_test = 'make check'
>
> then 'bzr switch upstream && bzr pull && bzr up-thread -a -m "Merging
> upstream."' will run 'make check' as it goes up each thread, stopping at
> the first error but otherwise committing with 'Merging upstream.'

I think the check at each level would be heavyweight for
some cases, for instance ./bzr selftest at each thread
would just take too long, so I would prefer to do it at
the top and then "bisect" if there was an error, however
I can see the reasoning.

Mentioning that, is there a use case for loom-bisect or similar?
I'll file another bug if you agree.

Thanks,

James

On Sun, 2008-02-24 at 21:57 +0000, James Westby wrote:
>
> I think the check at each level would be heavyweight for
> some cases, for instance ./bzr selftest at each thread
> would just take too long, so I would prefer to do it at
> the top and then "bisect" if there was an error, however
> I can see the reasoning.

For upstream to merge each patch separately, they will want each patch
appropriately tested. If we can define an interface that lets that
happen (for instance, for bzr, running a selected subset of tests in
each thread), then we're aiding the user in getting their code accepted:
and thats really the point :)

> Mentioning that, is there a use case for loom-bisect or similar?
> I'll file another bug if you agree.

Hmm, I think someone should play and see how it fairs; it may be that
bisect is just fine as is, or that loom should extend bisect when it is
installed.

-Rob

--
GPG key available at: <http://www.robertcollins.net/keys.txt>.
>