On Wed, 24 Nov 2010, Junio C Hamano wrote: > "J.H." <warthog9@xxxxxxxxxx> writes: > > > While I don't disagree, being able to support other caching systems > > would be nice, we have this now, it's tested and it works. I'd argue > > this is a step 1, step 2 case at this point. > > I would have to agree; getting some cache layer that is known to work (you > are battle testing your updates on a busy site of yours as you develop, > right?) early, quick and dirty with minimum changes, is more beneficial > than waiting for a large rewrite thats "gets it perfect this time". I also agree, that's why I'd like to go the "minimal fixups" route, where those minimal fixups are about caching being robust (loading cache.pl, passing minimal tests), not penalizing non-cached case (moving check for $caching_enabled out of cache_fetch), and make it possible to move to better solution / other caching engines in the future while maintaining backward copmatibility (configuration is API; $caching_enabled, perhaps also $cache (is 'cache.pl') and %cache_options). > > I'm currently working from on top of Jakub's last tree, though I've got > > some questions about his reasoning on a few things now that I've been > > digging into it. > > Thanks both for keeping the ball rolling. > -- Jakub Narebski Poland -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html