Plans for Loggerhead

Robert Collins robertc at
Wed Jan 7 03:00:11 GMT 2009

On Wed, 2009-01-07 at 15:49 +1300, Michael Hudson wrote:
> Robert Collins wrote:
> > I'd be extremely wary of overlapping with bzrlib here; fundamentally the
> > basics of loggerhead should be very thinly layered on bzrlib, if
> > something is too slow to show to a user in web time using bzrlib
> > directly, anything added on top is just complexity that will interfere
> > as bzrlib gets fixed to be fast enough. This has happened a few times
> > already - and when I look at loggerhead performance on brisbane core its
> > mainly using convoluted approaches on top of bzrlib api's that are
> > slower than they should be on production branches.
> Revision numbering is the thing that really causes pain.  Make that take
> a handful of milliseconds per revid, and life for loggerhead would get
> much, much, much easier.  But I'm not aware of any plans that might lead
> to this happening any time soon.

I think it does already, meantime-wise. The problem is that this only
applies if you get all 20K revision numbers at once :(.

The current numbering scheme is able to partially number without
accessing full history - and numbers near head are assigned more


GPG key available at: <>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : 

More information about the bazaar mailing list