Rev graph caching strategy (was Re: trac-bzr performance)

[Russ Brown]

On 11/28/2009 4:19 AM, Martin von Gagern wrote:
> Alexander Belchenko wrote:
>> Ian, it seems the problem much complex than that. trac-bzr is not bzr plugin, it's plugin for trac.
>> And as Aaron noted trac design is hugely different from usual bzr design. So it seems natural that
>> trac-bzr might need different type of cache.
>
> Nevertheless, the things Trac wants cached would probably be wanted by
> other apps as well. So what I think Ian has in mind is a bzr plugin, and
> if it is installed, trac-bzr can make use of it and speed things up, and
> if not, it either won't work (thus making the caching bzr plugin a hard
> requirement) or it will fall back to some less efficient approach.
> Sounds quite sensible to me.
>

I *think* that Alexander's point is that it could be tricky to use a bzr 
plugin from within trac.

That being the case, it may be better to implement as much of the 
caching infrastruture as possible in a generic python library that uses 
bzrlib. Then you can add a shell-like bzr plugin that just acts as an 
interface to that new library, and trac-bzr can use it too.

So you have:

bzr->bzr-cache->libbzrcache->bzrlib

and

trac->trac-bzr->libbzrcache->bzrlib

Just a thought.

-- 

Russ.