{"thread":{"id":"25068","subject":"[PATCH 1/2] gitweb: Make it possible to paginate projects","startedAt":"2010-09-10T16:17:20Z","lastAt":"2010-09-12T19:40:10Z","messageCount":9,"participants":["Lubomir Rintel","Jakub Narebski","J.H."],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"150448","messageId":"1284135442-10971-1-git-send-email-lkundrak@v3.sk","threadId":"25068","inReplyTo":null,"subject":"[RESEND] Pagination for gitweb","fromName":"Lubomir Rintel","fromEmail":"lkundrak@v3.sk","sentAt":"2010-09-10T16:17:20Z","receivedAt":"2010-09-10T16:17:20Z","isPatch":false,"sender":{"key":"lkundrak@v3.sk","avatar":"https://gravatar.com/avatar/0c78b09297e4f43bda3282627ada927e031aabd945d9a02df75ae525a18952a8?d=mp&s=160"},"body":"I tought something like this could be a starter for better handling long\ngitweb project lists (such as http://pkgs.fedoraproject.org/gitweb/).\n\nCould anyone please take a look?\nThanks!\n"},{"id":"150446","messageId":"1284135442-10971-2-git-send-email-lkundrak@v3.sk","threadId":"25068","inReplyTo":"1284135442-10971-1-git-send-email-lkundrak@v3.sk","subject":"[PATCH 1/2] gitweb: Make it possible to paginate projects","fromName":"Lubomir Rintel","fromEmail":"lkundrak@v3.sk","sentAt":"2010-09-10T16:17:21Z","receivedAt":"2010-09-10T16:17:21Z","isPatch":true,"sender":{"key":"lkundrak@v3.sk","avatar":"https://gravatar.com/avatar/0c78b09297e4f43bda3282627ada927e031aabd945d9a02df75ae525a18952a8?d=mp&s=160"},"body":"This adds simple pagination (next and prev links), to project lists,\nanalogous to what is done for commit history lists.\n---\n gitweb/gitweb.perl | 26 ++++++++++++++++++++++++++\n 1 files changed, 26 insertions(+), 0 deletions(-)\n\ndiff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\nindex a85e2f6..8dc7f29 100755\n--- a/gitweb/gitweb.perl\n+++ b/gitweb/gitweb.perl\n@@ -255,6 +255,9 @@ our %highlight_ext = (\n \tmap { $_ => 'xml' } qw(xhtml html htm),\n );\n \n+# Set this to non-zero to enable project list pagination\n+our $projects_per_page = 0;\n+\n # You define site-wide feature defaults here; override them with\n # $GITWEB_CONFIG as necessary.\n our %feature = (\n@@ -4613,9 +4616,19 @@ sub git_project_list_body {\n \tmy @projects = fill_project_list_info($projlist, $check_forks);\n \n \t$order ||= $default_projects_order;\n+\t$page ||= 0;\n+\tif ($projects_per_page) {\n+\t\t$from = $page * $projects_per_page unless defined $from;\n+\t\t$to = $from + $projects_per_page - 1 unless defined $to;\n+\t}\n \t$from = 0 unless defined $from;\n \t$to = $#projects if (!defined $to || $#projects < $to);\n \n+\tmy $prev_link = $cgi->a({-href => href(-replay=>1, page=>$page-1),\n+\t\t -accesskey => \"p\", -title => \"Alt-p\"}, \"prev\") if ($page > 0);\n+\tmy $next_link = $cgi->a({-href => href(-replay=>1, page=>$page+1),\n+\t\t -accesskey => \"n\", -title => \"Alt-n\"}, \"next\") if ($#$projlist > $to);\n+\n \tmy %order_info = (\n \t\tproject => { key => 'path', type => 'str' },\n \t\tdescr => { key => 'descr_long', type => 'str' },\n@@ -4709,6 +4722,19 @@ sub git_project_list_body {\n \t\tprint \"| $extra | \\n\" .\n \t\t \"\\n\";\n \t}\n+\n+\tif ($prev_link or $next_link) {\n+\t\tprint \"\\n\";\n+\t\tif ($check_forks) {\n+\t\t\tprint \" | \\n\";\n+\t\t}\n+\t\tprint \"\";\n+\t\tprint $prev_link if $prev_link;\n+\t\tprint \" ⋅ \" if $prev_link and $next_link;\n+\t\tprint $next_link if $next_link;\n+\t\tprint \" | \\n
\\n\";\n+\t}\n+\n \tprint \"\\n\";\n }\n \n-- \n1.7.2.1\n"},{"id":"150447","messageId":"1284135442-10971-3-git-send-email-lkundrak@v3.sk","threadId":"25068","inReplyTo":"1284135442-10971-2-git-send-email-lkundrak@v3.sk","subject":"[PATCH 2/2] gitweb: Optimize paging when sorted by path","fromName":"Lubomir Rintel","fromEmail":"lkundrak@v3.sk","sentAt":"2010-09-10T16:17:22Z","receivedAt":"2010-09-10T16:17:22Z","isPatch":true,"sender":{"key":"lkundrak@v3.sk","avatar":"https://gravatar.com/avatar/0c78b09297e4f43bda3282627ada927e031aabd945d9a02df75ae525a18952a8?d=mp&s=160"},"body":"There's no need to get authors, description and last modification time\nof a project that's not being shown on a current page. We can only tell\nthat in advance if the list is sorted by pathname.\n---\n gitweb/gitweb.perl | 47 ++++++++++++++++++++++++++++++++++-------------\n 1 files changed, 34 insertions(+), 13 deletions(-)\n\ndiff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\nindex 8dc7f29..a2e9a95 100755\n--- a/gitweb/gitweb.perl\n+++ b/gitweb/gitweb.perl\n@@ -4608,12 +4608,30 @@ sub format_sort_th {\n \treturn $sort_th;\n }\n \n+sub git_try_to_order {\n+\tmy ($projects, $order) = @_;\n+\n+\tmy %order_info = (\n+\t\tproject => { key => 'path', type => 'str' },\n+\t\tdescr => { key => 'descr_long', type => 'str' },\n+\t\towner => { key => 'owner', type => 'str' },\n+\t\tage => { key => 'age', type => 'num' }\n+\t);\n+\tmy $oi = $order_info{$order};\n+\treturn undef unless exists $projects->[0]->{$oi->{'key'}};\n+\tif ($oi->{'type'} eq 'str') {\n+\t\t@$projects = sort {$a->{$oi->{'key'}} cmp $b->{$oi->{'key'}}} @$projects;\n+\t} else {\n+\t\t@$projects = sort {$a->{$oi->{'key'}} <=> $b->{$oi->{'key'}}} @$projects;\n+\t}\n+\treturn 1;\n+}\n+\n sub git_project_list_body {\n \t# actually uses global variable $project\n \tmy ($projlist, $order, $from, $to, $extra, $no_header) = @_;\n \n \tmy $check_forks = gitweb_check_feature('forks');\n-\tmy @projects = fill_project_list_info($projlist, $check_forks);\n \n \t$order ||= $default_projects_order;\n \t$page ||= 0;\n@@ -4622,26 +4640,29 @@ sub git_project_list_body {\n \t\t$to = $from + $projects_per_page - 1 unless defined $to;\n \t}\n \t$from = 0 unless defined $from;\n-\t$to = $#projects if (!defined $to || $#projects < $to);\n+\t$to = $#$projlist if (!defined $to || $#$projlist < $to);\n \n \tmy $prev_link = $cgi->a({-href => href(-replay=>1, page=>$page-1),\n \t\t -accesskey => \"p\", -title => \"Alt-p\"}, \"prev\") if ($page > 0);\n \tmy $next_link = $cgi->a({-href => href(-replay=>1, page=>$page+1),\n \t\t -accesskey => \"n\", -title => \"Alt-n\"}, \"next\") if ($#$projlist > $to);\n \n-\tmy %order_info = (\n-\t\tproject => { key => 'path', type => 'str' },\n-\t\tdescr => { key => 'descr_long', type => 'str' },\n-\t\towner => { key => 'owner', type => 'str' },\n-\t\tage => { key => 'age', type => 'num' }\n-\t);\n-\tmy $oi = $order_info{$order};\n-\tif ($oi->{'type'} eq 'str') {\n-\t\t@projects = sort {$a->{$oi->{'key'}} cmp $b->{$oi->{'key'}}} @projects;\n-\t} else {\n-\t\t@projects = sort {$a->{$oi->{'key'}} <=> $b->{$oi->{'key'}}} @projects;\n+\t# If we're paginating and can order the list now (by pathname), we\n+\t# don't need to do an unnecessary and expensive query of the details\n+\t# of the projects we're not going to display. Attempt the sort and\n+\t# remove the other projects from the list if the sort is successful.\n+\t# Can't be used with ctags, since it needs a complete project list.\n+\tmy $ordered = git_try_to_order($projlist, $order)\n+\t\tunless gitweb_check_feature('ctags');\n+\tif ($ordered) {\n+\t\t@$projlist = @$projlist[$from..$to];\n+\t\t$to -= $from;\n+\t\t$from = 0;\n \t}\n \n+\tmy @projects = fill_project_list_info($projlist, $check_forks);\n+\tgit_try_to_order(\\@projects, $order) unless $ordered;\n+\n \tmy $show_ctags = gitweb_check_feature('ctags');\n \tif ($show_ctags) {\n \t\tmy %ctags;\n-- \n1.7.2.1\n"},{"id":"150460","messageId":"m34odxmnpj.fsf@localhost.localdomain","threadId":"25068","inReplyTo":"1284135442-10971-1-git-send-email-lkundrak@v3.sk","subject":"Re: [RESEND] Pagination for gitweb","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-09-10T18:57:44Z","receivedAt":"2010-09-10T18:57:44Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Lubomir Rintel writes:\n\n> I thought something like this could be a starter for better handling long\n> gitweb project lists (such as http://pkgs.fedoraproject.org/gitweb/).\n> \n> Could anyone please take a look?\n\nWhat do you mean here by \"better handling\"? \n\nIs the problem server performance for large number of projects? If\nthis is the problem, perhaps better solution would be to use caching\n(work in progress).\n\nIs the problem large projects-list page and bandwidth? There was a\npatch adding transparent compression of pages generated by gitweb\nwould be a better solution; perhaps this together with caching (to\navoid performance hit on CPU; note that usually gitweb performance is\nI/O and not CPU-bound).\n\nIs the problem client rendering performance on large page with large\ntable? If it is, then paginating output, or adding project search\nlike in gitweb fork used on http://repo.or.cz is correct solution.\n\n\nSo which is it?\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"150465","messageId":"4C8A816E.4090305@eaglescrag.net","threadId":"25068","inReplyTo":"m34odxmnpj.fsf@localhost.localdomain","subject":"Re: [RESEND] Pagination for gitweb","fromName":"J.H.","fromEmail":"warthog19@eaglescrag.net","sentAt":"2010-09-10T19:05:18Z","receivedAt":"2010-09-10T19:05:18Z","isPatch":false,"sender":{"key":"warthog19@eaglescrag.net","avatar":null},"body":"On 09/10/2010 11:57 AM, Jakub Narebski wrote:\n> Lubomir Rintel writes:\n> \n>> I thought something like this could be a starter for better handling long\n>> gitweb project lists (such as http://pkgs.fedoraproject.org/gitweb/).\n>>\n>> Could anyone please take a look?\n> \n> What do you mean here by \"better handling\"? \n> \n> Is the problem server performance for large number of projects? If\n> this is the problem, perhaps better solution would be to use caching\n> (work in progress).\n\nThey already moved to using my caching layer, mainly because I could\ncreate an RPM for them and the fact that my caching code is slightly\nmore battle tested.\n\n> Is the problem large projects-list page and bandwidth? There was a\n> patch adding transparent compression of pages generated by gitweb\n> would be a better solution; perhaps this together with caching (to\n> avoid performance hit on CPU; note that usually gitweb performance is\n> I/O and not CPU-bound).\n> \n> Is the problem client rendering performance on large page with large\n> table? If it is, then paginating output, or adding project search\n> like in gitweb fork used on http://repo.or.cz is correct solution.\n> \n> \n> So which is it?\n\nI think the issue is just having something like 10K projects all\nsuddenly staring you in the face on a single page, it's not so much a\ntechnical problem with gitweb itself as a mental problem of dealing with\na giant webpage like that.\n\nSo far the Fedora guys seem happy with the way things are (well except\nfor the fact that their front page takes something like 2 hours to\nbuild, which has it's own set of problems).\n\nJust some additional food for thought.\n\n- John 'Warthog9' Hawley\n"},{"id":"150462","messageId":"m3zkvpl8jf.fsf@localhost.localdomain","threadId":"25068","inReplyTo":"1284135442-10971-2-git-send-email-lkundrak@v3.sk","subject":"Re: [PATCH 1/2] gitweb: Make it possible to paginate projects","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-09-10T19:10:24Z","receivedAt":"2010-09-10T19:10:24Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Lubomir Rintel writes:\n\n> This adds simple pagination (next and prev links), to project lists,\n> analogous to what is done for commit history lists.\n\nLack signoff (see Documentation/SubmittingPatches).\n\n> ---\n> gitweb/gitweb.perl | 26 ++++++++++++++++++++++++++\n> 1 files changed, 26 insertions(+), 0 deletions(-)\n> \n> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\n> index a85e2f6..8dc7f29 100755\n> --- a/gitweb/gitweb.perl\n> +++ b/gitweb/gitweb.perl\n> @@ -255,6 +255,9 @@ our %highlight_ext = (\n> \tmap { $_ => 'xml' } qw(xhtml html htm),\n> );\n> \n> +# Set this to non-zero to enable project list pagination\n> +our $projects_per_page = 0;\n> +\n\nGood idea of being able to enable or disable pagination of projects\nlist. \n\nI am not sure though if this is the correct solution. First,\npagination in all other places is hardcoded to 100 items per page;\nIMHO for consistency it would be good to use the same page size\neverywhere.\n\nSecond, perhaps instead of yet another global variable a better\nsolution would be non-verridable %feature, like 'pathinfo' or 'forks'\nfeatures?\n\n> # You define site-wide feature defaults here; override them with\n> # $GITWEB_CONFIG as necessary.\n> our %feature = (\n> @@ -4613,9 +4616,19 @@ sub git_project_list_body {\n> \tmy @projects = fill_project_list_info($projlist, $check_forks);\n> \n> \t$order ||= $default_projects_order;\n> +\t$page ||= 0;\n> +\tif ($projects_per_page) {\n> +\t\t$from = $page * $projects_per_page unless defined $from;\n> +\t\t$to = $from + $projects_per_page - 1 unless defined $to;\n> +\t}\n\nHmmm...\n\n> \t$from = 0 unless defined $from;\n> \t$to = $#projects if (!defined $to || $#projects < $to);\n> \n> +\tmy $prev_link = $cgi->a({-href => href(-replay=>1, page=>$page-1),\n> +\t\t -accesskey => \"p\", -title => \"Alt-p\"}, \"prev\") if ($page > 0);\n> +\tmy $next_link = $cgi->a({-href => href(-replay=>1, page=>$page+1),\n> +\t\t -accesskey => \"n\", -title => \"Alt-n\"}, \"next\") if ($#$projlist > $to);\n> +\n\nIn other places we have 'first' ⋅ 'prev' ⋅ 'next'...\n\n> \tmy %order_info = (\n> \t\tproject => { key => 'path', type => 'str' },\n> \t\tdescr => { key => 'descr_long', type => 'str' },\n> @@ -4709,6 +4722,19 @@ sub git_project_list_body {\n> \t\tprint \"$extra | \\n\" .\n> \t\t \"\\n\";\n> \t}\n> +\n> +\tif ($prev_link or $next_link) {\n> +\t\tprint \"\\n\";\n> +\t\tif ($check_forks) {\n> +\t\t\tprint \" | \\n\";\n> +\t\t}\n> +\t\tprint \"\";\n> +\t\tprint $prev_link if $prev_link;\n> +\t\tprint \" ⋅ \" if $prev_link and $next_link;\n> +\t\tprint $next_link if $next_link;\n> +\t\tprint \" | \\n
\\n\";\n> +\t}\n\n... is there a reason to not use format_paging_nav() subroutine?\n\n> +\n> \tprint \"\\n\";\n> }\n> \n> -- \n> 1.7.2.1\n> \n\nSee also comments to next patch in series\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"150464","messageId":"m3vd6dl7wq.fsf@localhost.localdomain","threadId":"25068","inReplyTo":"1284135442-10971-3-git-send-email-lkundrak@v3.sk","subject":"Re: [PATCH 2/2] gitweb: Optimize paging when sorted by path","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-09-10T19:24:15Z","receivedAt":"2010-09-10T19:24:15Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Lubomir Rintel writes:\n\n> There's no need to get authors, description and last modification time\n> of a project that's not being shown on a current page. We can only tell\n> that in advance if the list is sorted by pathname.\n\nMore advanced version of this trick can be found in\n\n [RFC/PATCH] gitweb: Paginate project list\n http://thread.gmane.org/gmane.comp.version-control.git/80896/focus=81613\n\nfrom 2008-05-10. Perhaps it would be a good idea to merge these two\npatches?\n\n> ---\n> gitweb/gitweb.perl | 47 ++++++++++++++++++++++++++++++++++-------------\n> 1 files changed, 34 insertions(+), 13 deletions(-)\n> \n> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\n> index 8dc7f29..a2e9a95 100755\n> --- a/gitweb/gitweb.perl\n> +++ b/gitweb/gitweb.perl\n> @@ -4608,12 +4608,30 @@ sub format_sort_th {\n> \treturn $sort_th;\n> }\n> \n> +sub git_try_to_order {\n> +\tmy ($projects, $order) = @_;\n> +\n> +\tmy %order_info = (\n> +\t\tproject => { key => 'path', type => 'str' },\n> +\t\tdescr => { key => 'descr_long', type => 'str' },\n> +\t\towner => { key => 'owner', type => 'str' },\n> +\t\tage => { key => 'age', type => 'num' }\n> +\t);\n> +\tmy $oi = $order_info{$order};\n> +\treturn undef unless exists $projects->[0]->{$oi->{'key'}};\n\nNitpick: there is no need to use '->' between [0] and {$oi->{'key'}}.\nBTW is this sanity check necessary?\n\n> +\tif ($oi->{'type'} eq 'str') {\n> +\t\t@$projects = sort {$a->{$oi->{'key'}} cmp $b->{$oi->{'key'}}} @$projects;\n> +\t} else {\n> +\t\t@$projects = sort {$a->{$oi->{'key'}} <=> $b->{$oi->{'key'}}} @$projects;\n> +\t}\n> +\treturn 1;\n> +}\n\nNote that separating this part of code into subroutine is a good idea\nanyway, even if the final patch would look different.\n\n> +\n> sub git_project_list_body {\n> \t# actually uses global variable $project\n> \tmy ($projlist, $order, $from, $to, $extra, $no_header) = @_;\n> \n> \tmy $check_forks = gitweb_check_feature('forks');\n> -\tmy @projects = fill_project_list_info($projlist, $check_forks);\n> \n> \t$order ||= $default_projects_order;\n> \t$page ||= 0;\n> @@ -4622,26 +4640,29 @@ sub git_project_list_body {\n> \t\t$to = $from + $projects_per_page - 1 unless defined $to;\n> \t}\n> \t$from = 0 unless defined $from;\n> -\t$to = $#projects if (!defined $to || $#projects < $to);\n> +\t$to = $#$projlist if (!defined $to || $#$projlist < $to);\n> \n> \tmy $prev_link = $cgi->a({-href => href(-replay=>1, page=>$page-1),\n> \t\t -accesskey => \"p\", -title => \"Alt-p\"}, \"prev\") if ($page > 0);\n> \tmy $next_link = $cgi->a({-href => href(-replay=>1, page=>$page+1),\n> \t\t -accesskey => \"n\", -title => \"Alt-n\"}, \"next\") if ($#$projlist > $to);\n> \n> -\tmy %order_info = (\n> -\t\tproject => { key => 'path', type => 'str' },\n> -\t\tdescr => { key => 'descr_long', type => 'str' },\n> -\t\towner => { key => 'owner', type => 'str' },\n> -\t\tage => { key => 'age', type => 'num' }\n> -\t);\n> -\tmy $oi = $order_info{$order};\n> -\tif ($oi->{'type'} eq 'str') {\n> -\t\t@projects = sort {$a->{$oi->{'key'}} cmp $b->{$oi->{'key'}}} @projects;\n> -\t} else {\n> -\t\t@projects = sort {$a->{$oi->{'key'}} <=> $b->{$oi->{'key'}}} @projects;\n> +\t# If we're paginating and can order the list now (by pathname), we\n> +\t# don't need to do an unnecessary and expensive query of the details\n> +\t# of the projects we're not going to display. Attempt the sort and\n> +\t# remove the other projects from the list if the sort is successful.\n> +\t# Can't be used with ctags, since it needs a complete project list.\n> +\tmy $ordered = git_try_to_order($projlist, $order)\n> +\t\tunless gitweb_check_feature('ctags');\n> +\tif ($ordered) {\n> +\t\t@$projlist = @$projlist[$from..$to];\n> +\t\t$to -= $from;\n> +\t\t$from = 0;\n> \t}\n> \n> +\tmy @projects = fill_project_list_info($projlist, $check_forks);\n> +\tgit_try_to_order(\\@projects, $order) unless $ordered;\n> +\n> \tmy $show_ctags = gitweb_check_feature('ctags');\n> \tif ($show_ctags) {\n> \t\tmy %ctags;\n> -- \n> 1.7.2.1\n> \n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"150478","messageId":"201009102353.17279.jnareb@gmail.com","threadId":"25068","inReplyTo":"4C8A816E.4090305@eaglescrag.net","subject":"Re: [RESEND] Pagination for gitweb","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-09-10T21:53:14Z","receivedAt":"2010-09-10T21:53:14Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Fri, 10 Sep 2010, J.H. wrote:\n> On 09/10/2010 11:57 AM, Jakub Narebski wrote:\n> > Lubomir Rintel writes:\n> > \n> > > I thought something like this could be a starter for better handling long\n> > > gitweb project lists (such as http://pkgs.fedoraproject.org/gitweb/).\n> > >\n> > > Could anyone please take a look?\n> > \n> > What do you mean here by \"better handling\"? \n> > \n> > Is the problem server performance for large number of projects? If\n> > this is the problem, perhaps better solution would be to use caching\n> > (work in progress).\n> \n> They already moved to using my caching layer, mainly because I could\n> create an RPM for them and the fact that my caching code is slightly\n> more battle tested.\n\nNote that with project list pagination, and especially with project\nsearch feature, a better solution might be to cache *data* rather\nthan HTML output, like in fork used (or used to be used) by\nhttp://repo.or.cz, or in Lea Wiemann's GSoC 2008 project [1]\n\n[1] http://repo.or.cz/w/git/gitweb-caching.git\n-- \nJakub Narebski\nPoland\n"},{"id":"150547","messageId":"201009122140.10926.jnareb@gmail.com","threadId":"25068","inReplyTo":"4C8A816E.4090305@eaglescrag.net","subject":"Re: [RESEND] Pagination for gitweb","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-09-12T19:40:10Z","receivedAt":"2010-09-12T19:40:10Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Fri, 10 Sep 2010, J.H. wrote:\n> On 09/10/2010 11:57 AM, Jakub Narebski wrote:\n \n> > Is the problem server performance for large number of projects? If\n> > this is the problem, perhaps better solution would be to use caching\n> > (work in progress).\n> \n> They already moved to using my caching layer, mainly because I could\n> create an RPM for them and the fact that my caching code is slightly\n> more battle tested.\n\nIs this RPM site-specific, or generic one? Could you share *.spec file?\nOr do you use git.spec from git, just use patched gitweb?\n-- \nJakub Narebski\nPoland\n"}]}