Re: [PATCH 3/3] gitweb: use new Git::Repo API, and add optional caching

From: Jakub Narebski <jnareb@gmail.com>
Date: Jul 15, 2008, 00:52 UTC
Message-ID: <200807150252.52604.jnareb@gmail.com>
In-Reply-To: <487BE7C4.2050207@gmail.com>

On Tue, 15 July 2008, Lea Wiemann wrote:

Show 5 quoted lines

> Jakub Narebski wrote:
> > 
> > Could you explain then how gitweb cache is invalidated?
> 
> Sure; from gitweb.perl:

I'll try to read and comment on patch itself soon.

Show 5 quoted lines

> # Transient cache entries (like get_sha1('HEAD')) are automatically
> # invalidated when an mtime of either the repository's root directory
> # or of the refs directory or any subdirectory changes.  This
> # mechanism *should* detect changes to the repository reliably if you
> # only use git or rsync to write to it,

Nice idea... for project pages. I'm not so sure about projects_list page, if wouldn't be better to have expire time for *this* page. You would have/have to stat a lot of files/directories to detect changes.

BTW. some summary of the above should be IMHO in the commit message.
In short, you should write, I think, that caching mechanism uses
any Cache::Cache compatible cache for caching data, that large objects
can be cached on filesystem (or perhaps not, at it is a detail), that
cache validity is checked by stat-ing refs area.

Show 11 quoted lines

> IOW, gitweb will do a small number of (inexpensive) stat calls on those
> directories each time it's called, and use the most recent mtime as part
> of the cache key for transient entries.  Hence those transient entries
> will automatically become invalid once the most recent mtime changes.
> 
> (If any of the relevant directories has been modified since the last
> time gitweb checked, gitweb will re-scan the whole tree to check for new
> directories, and record their mtimes as well.  See get_last_modification
> if you're interested in more gory details.)
> 
> The punchline is, the cache never returns outdated data.

In this case you don't have any basis to set expires for transient views; on the other hand situation doesn't differ much from serving static files (wrt. cache validation) so perhaps no expires but no "no-cache" would be a good solution.

P.S. is there any cache evision mechanism (to limit cache size) in gitweb cache, or just those implemented by caching backend?

-- 
Jakub Narebski
Poland