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

[Thomas Keller]

Nathaniel Smith wrote:
> It looks like you basically figured this out -- the important thing to
> notice is the difference between "parent/child" and
> "ancestor/descendent".  If you have A -> B -> C, then A is an ancestor
> of C, but it is not a parent of C.  We try to be careful about these
> two words, since the difference really is important :-).

I *think* this is taken care of in the previously quoted SQL and I also 
think I know the difference between anchestor/desendent and parent/child =)
Now, the more important issue for me is speed: I tried to track it down 
why it took around 4 - 5 seconds on my machine for mtn to determine the 
head(s) of the net.venge.monotone branch, while on other branches this 
took only around 800ms. So I looked at the source code and tried to 
understand what it does and gave up around the section where 
erase_anchestors starts (since there is no commentary in the code in 
this area and I'm not familiar with the magic which is done there).

Thomas Moschny mentioned the distinction between heads and leaves, a 
"global" (i.e. without taking branches into account) leave is most 
likely a head, while a "local" leave just might be an endpoint of one 
development line which may later be ressurrected:

branch a:                D -> E -> F
                        /           \
branch b:    A -> B -> C             G

Here, on the first view C and G seem to be valid heads, but since G is a 
descendent from C, C actually is no head, but just a leave in branch b.

Now, I don't know if I catched it all, but if thats really all the 
magic, can't this reflected by the following SQL?

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

Feeding this SQL into mtn db execute and timing it showed me a duration 
of about 400ms (and this could be probably made even faster with the 
right use of SQL Indexes).

> <tommyd> its just that I'd like to expand the format of autmate branches
>   a bit and display the revision ids of the head revisions along to the
>   branch's name, and if the branch is not merged, handle that
>   accordingly by displaying all head revisions and their other certs
>
> I don't much like this idea at all.  If someone wants that extra
> information, they can already get it with "automate heads" or even
> "automate select".

Ok, if it is super-hazardous to expose the same data more than once in 
the interface, you're right and I'm beaten. For me, even with the use of 
automate stdio, its more a puzzle to collect all the needed data, since 
I'd need to do

1) one call for automate branches
2) X calls for each branch to get its head revs via automate heads
3) Y calls for each head rev to get its certs via automate certs

I haven't implemented this, but a feeling tells me that this *could* be 
slower than getting it all via automate branches.

> Getting that extra information is an extra
> cost, and we should make our interfaces orthogonal, so that each
> consumer pays only for the information that they request.  (I.e., what
> do I do if I really _do_ just want the branch names?)

Use mtn heads? This is a academic discussion since automate branches 
exists since 0.28 and I doubt we can ask anyone at this point if he/she 
just wants the branch name or cares at all if he/she gets more info on 
the same run (and just picks out the needed data)...

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