Re: [Gnu-arch-users] tla-pqm 0.2

[Colin Walters]

On Fri, 2003-10-17 at 17:09, Joshua Haberman wrote:

> I think this highlights my incomplete understanding of arch's
> star-merge.  Specifically: how is a star-merge from A to B different
> from sequentially applying to B all changesets that A has that B doesn't
> have?  

In other words, you want to just apply all the changesets in 'tla
missing B'?

Well, because for one thing B might have skipped changesets from A in
the past, by cherry-picking.  B decided that they just didn't want some
changes that A made, but did want others.

star-merge solves this by just going back to the last merge point.

And in general, you have to keep in mind that some of the patches
applied to the development branch will be merges from the mainline...and
if you just applied those changesets back to the mainline, you would get
conflicts (since the changes were already there).  Again star-merge's
technique of going back to the last merge point on either side solves
this.

> Doesn't every branch have a list of all changesets that have ever
> been applied to it, directly or indirectly through a merge?

Yeah.

> Why is it wrong to think of a merge request as a submission of a
> sequence of changesets that already exist on the development branch?

I wouldn't say that's wrong.  The trick is in the computation of that
sequence.

> > Yes...I think the way to implement this though would be to have the
> > people who can approve changesets run their own tla-pqm instances.  Then
> > instead of submitting merge requests to example-dev, the sub-satellite
> > developers submit them to the main developers.
> 
> This is undesirable for the projects where I would like to use Arch.  It
> presupposes that for a particular changeset there is a developer with
> write access who is known to be capable and willing to review a
> particular patch.  What I think is more likely are situations where
> there is a generic patch that any of several developers could review and
> accept, and whoever has time to review the patch queue first should
> accept/reject it.

Ok.  It's possible that eventually tla-pqm might morph into something
like this.  It would be pretty cool, I agree.

signature.asc
Description: This is a digitally signed message part