Bruno Ribas <ribas@xxxxxxxxxxxx> writes:
> After some study about the insertion of a new repository configuration,
> which sets repository owner, it was decided by the group that creating
> another small file inside .git/ is not a good idea. So I started to bench
> the viability to add just the gitweb.owner configuration, using gitweb.owner
> together with gitweb.description there is no major performance downgrade
> compared to $projects_list , as seen below:
>
> 8<-------
> These times i got with a 1000projects running 2 dd to generate disk IO.
> Here comes the resultm
> NO projects_list projects_list
> 16m30s69 15m10s74 default gitweb, using FS's owner
> 16m07s40 15m24s34 patched to get gitweb.owner
> 16m37s76 15m59s32 same above, but without gitweb.owner
>
> Now results for a 1000projects on an idle machine.
> NO projects_list projects_list
> 1m19s08 1m09s55 default gitweb, using FS's owner
> 1m17s58 1m09s55 patched to get gitweb.owner
> 1m18s49 1m08s96 same above, but without gitweb.owner
> 8<-------
It looks like there is almost no difference between using only FS
owner, and reading also repository config using "git config -z -l"...
Could anyone using gitweb on MS Windows or MacOS X, where fork is mich
slower, check those figures?
Pasky, could you please try to benchmark this (well, at least without
gitweb.owner set) on a _real_ large set of repositories?
> The idea of creating only the gitweb.owner can be a case of study to
> centralize all gitweb repository configuration in one file. Maybe even
> change the way $projects_list is formated, as gitweb.cgi needs to check
> repository configuration to get repository description to generate
> project_list page, we could just list repository's directories.
I was thinking about git-config-like format (but simplified to make it
easy to parse it in Perl, just like git-cvsserver configuration), in
the form of
[gitweb "<repository path, relative to $projectroot>"]
description = <project description>
url = <first URL>
url = <seconf URL>
owner = <repository owner>
The problem with parsing lies (among others) in the in-line comments,
novalue keys, and key after section, I think...
--
Jakub Narebski
Poland
ShadeHawk on #git
-
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
