On Tue, 13 May 2008, Lars Hjemli wrote:
quoted text
> On Tue, May 13, 2008 at 8:55 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>>
>> But please take into account that gitweb performance, and I guess any
>> git web interface performance, is I/O bound and not CPU bound (at least
>> according to what I remember from J.H. emails).  So a little more
>> processing is I think less important than avoiding hitting the repos.
> 
> Yeah, that's a pretty convincing argument for "cache the data, not the
> output", at least for gitweb (cgit never touches the repos to generate
> the project list/search).

First, this is less argument for "cache data" against "cache output",
only against disregarding "cache data" for assumed performance reasons,
while it "cache data" can be useful in some places.


Second, gitweb's projects list page contains "Last Changed" column,
and you _*have*_ to hit repositories for this data, and backwards
compatibility prevents from removing that.

You can configure gitweb in such way that project name, owner, and
project description are read from single 'project_index' file with 
  "gitweb: Allow project description in project_index file"
patch.  repo.or.cz can do this.

On the other hand mechanism to scan directory, getting owner from
filesystem owner (plus GECOS) or repository's gitweb.owner configuration,
and project description from 'description' file in projects repository,
allow to treat gitweb in similar way to mod_userdir i.e. as service.
You don't need to register project with gitweb; you need only to create
it in appropriate place (or put symbolic link there).  kernel.org
functions this way.

I wonder how Freedesktop.org does it: it offers both gitweb and cgit
interfaces, if I remember correctly...
-- 
Jakub Narebski
Poland
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html