[RFC] Loggerhead's caching architecture

[Ian Clatworthy]

John,

I've been pondering our (phone) discussion re caching in Loggerhead 
today. I agree that we ought to use history-db where we can rather than 
maintain custom caching inside loggerhead.

Here as the choices as I understand them.

1. Making history-db completely optional. If's it there and configured, 
use it for caching, otherwise don't.

2. Make history-db mandatory but make the disk cache optional.

3. Make history-db mandatory and require the disk cache to be configured.

(1) is ideal from my perspective but the most work for you. I remain 
hesitant about (3), i.e. making a SQL db a mandatory part of every 
loggerhead deployment.

The downside to (1) and (2) is that some operations (like finding where 
a revision is merged) will be *really* slow on large branches when it's 
not there. FWIW, I'm OK with only enabling certain functionality when 
the disk cache is there. In fact, I think we ought to encourage that 
pattern: fast out of the box and controlled enablement of "expensive" 
features.

I think we definitely want configuration settings to control where the 
disk cache is located. Configuring the cache to be per (shared) 
repository needs to be trivial IMO. Other schemes - like per-project on 
Launchpad - need to be possible.

Maybe (2) is the right compromise. Can history-db be enhanced to support 
using a memory cache when the disk cache is not configured?

Ian C.