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

[Nathaniel Smith]

On Mon, Aug 07, 2006 at 02:51:01AM +0200, Thomas Keller wrote:
> 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

Okay, I've spent a few minutes staring at this, and I give up :-).
Can you break down what it does in English?

> ><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

It's not super hazardous -- there just should be some reason.

> 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.

Speed is a reason.  But why do you think this could be slower?
Monotone can't use any smarter of an algorithm then the one you
outline here -- it would run the code that 'automate branches' runs,
then do a loop over that and run the code that 'automate heads' runs X
times, etc.

There are only two advantages I see:
  -- You save a _little_ bit of time not having to parse multiple
     automate command requests.  But this is almost nothing.
  -- The API for users is a little bit simpler... but the API for my
     proposal is not at all complicated either.  In python, it would
     look like:

def get_lots_of_head_info(mtn):
    branches = mtn.branches()
    heads = {}
    for branch in branches:
        heads[branch] = mtn.heads(branch)
    certs_for_head = {}
    for head_set in heads.itervalues():
        for head in head_set:
            certs_for_head[head] = mtn.certs(head)
    return heads, certs_for_head

Easy to read and straightforward, and could actually be made even
shorter with some judicious use of list or generator comprehensions,
e.g.
    heads = dict((branch, mtn.heads(branch)) for branch in mtn.branches())
already gives you all branches and all heads, in one line, about as
efficiently as anything can :-).

The acid test for speed questions, of course, is to time it... if you
really want to convince yourself either way, you could both and see
:-).

-- Nathaniel

-- 
So let us espouse a less contested notion of truth and falsehood, even
if it is philosophically debatable (if we listen to philosophers, we
must debate everything, and there would be no end to the discussion).
  -- Serendipities, Umberto Eco