Jakub Narebski wrote:
Nagy Balázs wrote:
Are you talking about I/O of an all-in CGI script?
I am talking there between I/O difference between situation
(configuration) when $projects_list is a directory (default),
or is a file. If $projects_list is a directory, gitweb scans
directory structure to find git repositories, which for large
number of repositories might take time, even with filesystem
cache, and with depth of searching bound by $project_maxdepth.
Add to that finding symbolic name of the owner of repository
directory, or (with the patch) reading a file per repo with repo
owner.
We have two configurable options here: $projectroot and $projects_list.
If $projects_list is a directory, we'll end up using a directory to get
project list info, and using another one to actually handle the
projects. In small repo area it's safe to have $projects_list empty.
This is why I reference $projects_list as a file.
If $projects_list is a file, we'll rely on a file which was generated
some time ago and can't reflect the latest changes of $projectroot (but
see below).
We can tune the
performance of this script, but changing the GIT_DIR structure just
because of a simple script is a bit overkill to me.
What if this script creates the $projects_list file, for example when
the $projectroot's mtime changes? We can even hold mtime info for every
project's config file.
I don't understand what you wanted to say here. $projects_list file
lists only project path (project name) and project owner.
I mean it would be better to add this kind of metadata like description
and owner's shoesize to config instead of a raw file. I understand row
files are easier to read but reading a single cache file adn doing some
stat()s are much easier. I can think of $project_lists as a cache file
name, which can be maintained by gitweb.cgi, and these mtime values
could be saved to $project_list to verify entries' validity.
All we have to do is to maintain $project_list to be up to date. The
best would be to have a separate projectlist maintainer script which
handles two scenarios:
1| repo addition/deletion
2| repo config changes
I don't have solution for the first scenario which would be a speed
improvement in gitweb.cgi, this is why I suggest to put $project_list
updater to a separate script. The second scenario could be handled by
gitweb.cgi though, but it would be mere code duplication.
Regards:
--
Balazs Nagy
-
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
