Re: [Monotone-devel] responses to some IRC discussion of 'automate'

[Thomas Keller]

Timothy Brownawell wrote:
> > > > SELECT ra1.child
> > > > FROM revision_ancestry ra1
> > > > LEFT JOIN revision_ancestry ra2 ON ra1.child=ra2.parent
> > > > INNER JOIN revision_certs rc ON ra1.child=rc.id AND rc.name="branch" 
> > > > AND rc.value LIKE "net.venge.monotone"
> > > > WHERE ra2.parent IS NULL
> > > > GROUP BY ra1.child
> [...]
> It does not work for branches where the branch heads aren't leaves in
> the revision graph. For example, it fails on net.venge.monotone.visualc8
> or net.venge.monotone.tbrownaw.tester-spinoff .

Yep, you're right. This beats my approach and there is nothing I could 
think of which with this could be handled (since I doubt SQLite supports 
recursive queries).
Then I second Thomas Moschny's suggestion to - at least - tune 
erase_ancestors in that way that only the anchestry of those revisions 
are calculated which are leaves within the branch. Finding those is easy:

SELECT ra1.child
FROM revision_ancestry ra1
LEFT JOIN revision_ancestry ra2 ON ra1.child=ra2.parent
INNER JOIN revision_certs rc1 ON ra1.child=rc1.id AND rc1.name="branch"
INNER JOIN revision_certs rc2 ON ra2.child=rc2.id AND rc2.name="branch"
WHERE rc1.value LIKE "net.venge.monotone.visualc8" AND (ra2.parent IS 
NULL OR rc1.value!=rc2.value)

Executing this actually gives you the correct head revid for the 
nvm.visualc8 branch, but quite a lot more revisions e.g. on 
net.venge.monotone which would need to be checked by erase_ancestors 
afterwards.

> It also doesn't allow for checking to see if we actually trust the
> branch certs we're using.

Well, this is another story, but could be handled by a few more AND's as 
well (and a query for trusted branch certs beforehand).

Thomas.

--
- "I know that I don't know." (Sokrates)
Guitone, a frontend for monotone: http://guitone.berlios.de
Music lyrics and more: http://musicmademe.com