[whups] Re:

[Anil Madhavapeddy]

Quoting Chuck Hagenbuch <chuck@horde.org>:

> Yeah... speaking about Horde specifically, well, I'm not _too_ ashamed that
> the  system was NOT well designed from the start. 

I think that was its strength, as it is for a lot of open-source code.
Over-engineering from the start just leads to the code collapsing under
its own weight before getting off the ground; much better if it does the
job for what it needs to do at the time, when time and money aren't 
freely flowing, and the code gets used.

> Anil, if you decide on a name for the cvs viewer, I'll move
> the files in the repository so we don't lose any history...

Great, give me all the hard jobs! I better dig out my IKEA catalogue ;-)

> Okay, let's talk about the caching backend: is the db schema that you
> mentioned earlier (from bonsai) going to handle this particular need?
> Is it absolutely reliant on having a database? Or could this be more 
> general - either a general caching scheme, or a cvs caching scheme
> generalized over multiple backends?

Afaics, the bonsai backend absolutely requires a database backend.
However, I've changed my mind a bit about bonsai support, since all
that it takes to setup the database is to run a script over the CVS
repository.  So if we come up with a better schema for our needs, we
might as well use that.

I think a CVS caching scheme that would first look in a database
cache (dbm, sql, gdbm, shm, whatever), and then fallback to the 
file directly if that isn't present (out-of-date cache, dummy db driver
for those without databases) would be good.

Certain queries aren't so much a cache-query, as a view-query.
For example, 'what damage has avsm done to the repository in the last
two days'.  This would pretty much require the cache to be fully
populated, as it wouldnt be feasible to iterate through the entire
repository and populate it for that request.

> But, really, I don't see any reason to try harder than necessary to avoid 
> requiring a database for this. It might be nice if most things worked without
> any cache at all, but someone running a cvs repository is probably going to 
> have a database available to them. So if generalizing it to more than
> "generic  sql" is silly, forget it.

Up to now, the functionality hasn't required a database, so I think
it would be worthwhile to allow users to set something up that goes this
far, without needing a database.  If they want the additional functionality,
I see no reason why we shouldn't just require it.

I haven't even glanced at the PEAR::DB stuff yet; have stuck that on my
TODO list.

> - when a user searches the faq, bug reports are also searched. This way
> people find out if a bug is open, or has already been fixed, with one 
> search, instead of two.
> 
> - it should be easy to maintain a link to a revision of a file (ie, without 
> hardcoding a full url - just the revision and filename), to be used for
> example in the bugs interface so that if you go to a closed bug, you get a 
> link to the patch that fixed it.

These all sounds great, and entirely feasible to do!

-- 
Anil Madhavapeddy, <anil@recoil.org>