Re: [Monotone-devel] Suspend certs...

[William Uther]

On 12/08/2007, at 11:39 PM, Nathaniel Smith wrote:

> What about discontiguous branches?  If you have A1 -> B1 -> A2, then
> the above SQL will report both A1 and A2 as heads for branch A.

I told you I didn't trust my logic.

> > The next thought was to use heights (as suggested in the comment).
> > That would stop short branches from iterating over the entire
> > ancestry.  I have a fairly busy week, and mtn ls branches is not
> > horrendous any more.  I'll look at it when I have time.
>
> Yeah, I can see heights helping in the find-heads-of-everything case
> for sure...

The attached patch adds height processing to  
erase_ancestors_and_failures().  It reduces the 'mtn ls branches'  
time from 6s down to 3s.  I haven't committed it because I think it  
needs a little more experimentation:

  - Does the height gathering slow down other operations?  (e.g.  
get_heads on n.v.m)  Is the trade-off worthwhile?
  - At the moment I cache heights that I gather.  Is this worthwhile?
  - At the moment I assume heights exist for all revisions, but I  
note that there is a db.has_rev_height() function.  There probably  
should be more checking going on.
  - At the moment I'm caching the heights inside  
erase_ancestors_and_failures().  Should that be moved to the main  
db.get_rev_height() function?
  - At the moment there is no way to clear the heights cache.  So if  
you're using, say, 'mtn automate stdio', once you've gathered the  
heads of a revision there is no way to free the memory used.

I'm pretty sure that many of these are not issues, but as I said,  
more testing required.

I wont be able to get to this soon.  The patch is attached for others  
who want to play.

Be well,

Will           :-}

heights.patch
Description: Binary data