brisbane: initial cut at a mergeline cache

[Robert Collins]

On Mon, 2009-03-30 at 13:46 +1000, Ian Clatworthy wrote:
> Ian Clatworthy wrote:
> 
> So the key thing I forgot to mention is that this makes *all*
> operations on a non-mainline revision faster, not just log.
> For example:
> 
> * bzr log -rx.y.z  drops from 6.03s to 0.75s
> * bzr st -rx.y.z   drops from 5.87s to 1.68s
> * bzr diff -rx.y.z drops from 6.49s to 2.09s
> 
> And that's just bzr.dev - really large projects like Emacs & OOo
> will see *much* larger reductions.

Those are nice figures. However I'd like to note that we used to have a
similar thing [just the mainline revs at that point] and we removed it.
I'm really not sure this is the right approach to solving the problem.

> > 3. Updating a cache in the middle of a 'read' operation causes
> >    grief I don't know how to fix. How does one go about promoting
> >    a read-lock to a write-lock in bzrlib?
> 
> I've worked around this in the latest patch by updated the cache
> on disk after the read transaction completes. I'm less than happy
> with what that implies: an extra flush() method on branch() that
> commands in builtins.py needs to remember to call after b.unlock().
> If there's a way of making unlock() do this magic implicitly,
> I'd be much happier. Certainly *I* couldn't make it work thanks to
> our decorators that put each of my attempts into endless
> recursive loops. :-(
> 
> Thoughts?

Don't update on read operations, its not safe, and unlike dirstate there
is no need to do so as only write-locked operations can change the state
it would cache.

-Rob
-------------- 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 : https://lists.ubuntu.com/archives/bazaar/attachments/20090330/eafeb08b/attachment.pgp