On Thu, 18 Nov 2010, Junio C Hamano wrote: > Jakub Narebski <jnareb@xxxxxxxxx> writes: > >> Sidenote: recently sent >> >> gitweb: selectable configurations that change with each request >> >> practically reverts >> >> gitweb: Move call to evaluate_git_version after evaluate_gitweb_config >> >> Just FYI. > > Hmph, will have to look at it again. A bit of history: * c2394fe (gitweb: Put all per-connection code in run() subroutine, 2010-05-07) a0446e7 (gitweb: Add support for FastCGI, using CGI::Fast, 2010-05-07) those added run() and run_request(), separating "main" code of gitweb from code that is run once per requect (once per connection). * 869d588 (gitweb: Move evaluate_gitweb_config out of run_request, 2010-07-05) among others moved evaluate_gitweb_config out of run_request() to run(), because I thought that gitweb config that changes per-request is vanishingly rare: it isn't (e.g. gitolite has parts that are per-request). evaluate_git_version was moved *together* with evaluate_gitweb_config. * 7f425db (gitweb: allow configurations that change with each request, 2010-07-30) partially reverted commit 869d58... but forgot to move evaluate_git_version when moving evaluate_gitweb_config. This didn't matter in most cases... except for test suite. * 8ff76f4 (gitweb: Move call to evaluate_git_version after evaluate_gitweb_config, 2010-09-26) fixed that issue, in a simplest way, by moving evaluate_git_version after evaluate_gitweb_config. + 0ac5f64 (gitweb: selectable configurations that change with each request, 2010-11-18) in my 'gitweb/web' branch solves the issue in other way: evaluate_gitweb_config is run first time outside of run_request(), and on subsequent requests in run_request() (by default). So evaluate_gitweb_config is back before evaluate_git_version. Hence there is no need to move evaluate_git_version. HTH. >>> * jn/gitweb-time-hires-comes-with-5.8 (2010-11-09) 1 commit >>> - gitweb: Time::HiRes is in core for Perl 5.8 >>> >>> Looked reasonable. Will merge to next. >> >> Thanks. With or without improvement to commit message? > > I think what I pushed out has already been reworded. Please check. I have checked the version in 'pu' and it looks good. Thanks. >>> * jh/gitweb-caching (2010-11-01) 4 commits >>> . gitweb: Minimal testing of gitweb caching >>> . gitweb: File based caching layer (from git.kernel.org) >>> . gitweb: add output buffering and associated functions >>> . gitweb: Prepare for splitting gitweb >>> >>> Temporarily ejected while I shuffled jn/gitweb-testing; will queue the >>> latest back in pu or perhaps in next. >> >> The advantage of 'gitweb: File based caching layer (from git.kernel.org)' >> is that it is tested in real-life on heavy load (assuming that >> git.kernel.org uses the same version as is/would be in pu/next). >> >> The disadvantage is that it is seriously messy code. Something that I >> wanted to improve in my rewrite. This is only minimal fixup. > > Which is exactly what we want at this point (I want to release 1.7.4 by > the end-of-year holidays, which means a feature-freeze will have to start > soon). My understanding is that the serious messiness does not come from > the caching layer. Well... the capturing, caching and actual gitweb operations are quite intermixed in J.H. patch. I wanted to separate those issues, and have them modularized in my rewrite[1], making it easy to use other caching engine (tested with Cache::FileCache from Cache::Cache). On the other hand intermixing allows capturing directly to cache file (although it is only since v7), something that would be more difficult in my rewrite. The Perl code of J.H. patch does not follow style of other parts of gitweb, doesn't follow best practices (like e.g. using lexical filehandles instead of globs), does include some code repetitions... all of which made me attempt rewrite rather than fix it. [1] http://repo.or.cz/w/git/jnareb-git.git http://github.com/jnareb/git 'gitweb/cache-kernel-pu' branch BTW. I didn't get any responses to "[RFC] Implementing gitweb output caching - issues to solve". -- Jakub Narebski Poland -- 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