All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Petr Baudis <pasky@suse.cz>
Cc: git@vger.kernel.org, "J.H." <warthog19@eaglescrag.net>,
	Frank Lichtenheld <frank@lichtenheld.de>
Subject: Re: [RFC/PATCH 3/3] gitweb: Fill project details lazily when caching
Date: Tue, 18 Mar 2008 10:12:09 +0100	[thread overview]
Message-ID: <200803181012.11273.jnareb@gmail.com> (raw)
In-Reply-To: <20080318031406.GH10335@machine.or.cz>

On Tue, 18 March 2008, Petr Baudis wrote:
> On Mon, Mar 17, 2008 at 04:09:30PM +0100, Jakub Narebski wrote:
>>
>> If caching is turned on project details can be filled in already from
>> the cache.  When refreshing project info details for all project (when
>> cache is stale and has to be refreshed) generate projects info only if
>> modification time (as returned by lstat()) of projects repository
>> gitdir changed.
>> 
>> This way we can avoid hitting repository refs, object database and
>> repository config at the cost of additional lstat.
>> 
>> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
>> ---
>> This is an idea for further improvement of 'projects list caching'.
>> Could you please: 
>> 
>>  1.) comment if it is a good idea, or why it works, or why it
>>      couldn't work :),  
> 
> The idea is nice, but I'm surely missing something obvious again - why
> do you use lstat() as opposed to stat()?

Because in my home installation of gitweb (for tests) I have 
/home/local/scm/git.git symlinked to /home/jnareb/git/.git
And I want to follow changes in repository; link itself doesn't
change.

> And more importantly, the mtime 
> of projects repository unfortunately does not reflect almost any
> changes per se; you would need to check mtime of description file,
> config file and the refs instead.

Well, I had hopes that because git uses "write to temporary file, rename
temporary file to final name" to have atomic file writes any change in
git repository would be reflected in mtime of topdir / GIT_DIR. I have
checked it superficially... by doing a fetch, and a commit. But while
both fetch and commit manipulate files in top dir (FETCH_HEAD, ORIG_HEAD,
COMMIT_EDITMSG) it is not the case for push, unfortunately. If all
pushes would result in pack transfer, it would be enough to watch for
GIT_DIR/objects/pack/ directory.

I think that nothing short of inotify or equivalent would work: it is
just too many files/directories to watch for changes... I hope I am
mistaken here...

-- 
Jakub Narebski
Poland

  reply	other threads:[~2008-03-18  9:13 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-17 15:09 [PATCH 0/3 v2] gitweb: Support caching projects list Jakub Narebski
2008-03-17 15:09 ` [PATCH 1/3] gitweb: Separate @projects population into git_get_projects_details() Jakub Narebski
2008-03-17 15:09 ` [RFC/PATCH 2/3] gitweb: Support caching projects list Jakub Narebski
2008-03-17 16:54   ` Frank Lichtenheld
2008-03-17 18:52     ` Jakub Narebski
2008-03-17 19:10       ` Frank Lichtenheld
2008-03-17 20:25         ` Jakub Narebski
2008-03-17 15:09 ` [RFC/PATCH 3/3] gitweb: Fill project details lazily when caching Jakub Narebski
2008-03-18  3:14   ` Petr Baudis
2008-03-18  9:12     ` Jakub Narebski [this message]
2008-03-18  9:52       ` Frank Lichtenheld

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200803181012.11273.jnareb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=frank@lichtenheld.de \
    --cc=git@vger.kernel.org \
    --cc=pasky@suse.cz \
    --cc=warthog19@eaglescrag.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.