When to use invalidate()

[Greg Ward]

On Tue, Feb 2, 2010 at 2:44 AM, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
> hgweb (in hgweb_mod.py) should re-instantiate the repo on each request
> where the mtime for .hg has changed. If you think there's something to
> be improved there, let's hear it (though I think invalidate()ing just
> before discarding the repo probably doesn't make much sense).

Ahh.  I get it; thanks for the pointer.

Problems with this:

  * hgweb re-reads config when 00changelog.i has changed, not when
config has changed... so if you edit config on the server, nothing in
hgweb changes until someone pushes to the repo.  If my analysis is
correct, that sounds confusing as heck!
  * knowledge about repository structure lives in hgweb, not in
localrepository (so it's hard for e.g. THG to take advantage of this
to detect when it needs to refresh)
  * no clear way for extensions to hook into the process and let their
state be torn down when the repo state is torn down
  * no clear way for extensions to detect/announce that they have
stale state that needs to be torn down
  * no consistent way for all long-running apps (hgweb, THG, hgview,
...) to tear down repo state at the end of some processing phase (HTTP
request, window focus, user hits "refresh", ...)

In the short term, I'm going to see if my bugmap extension can figure
out when it's running in hgweb, and if so wrap hgweb.refresh().  If
that works, it should fix the bugs that require me to login to the
server and kill the mod_wsgi processes a couple of times per day.

But I suspect there is a more elegant solution waiting to emerge.
Perhaps localrepository() needs a method isstale().  Rough sketch:

  * constructor sets mtime (from 00changelog.i?)
  * isstale() compares current mtime of 00changelog.i to self.mtime
  * long-running apps call isstale() and do the right thing
(invalidate(), re-instantiate, whatever)
  * extensions with state can wrap isstale() and insert their own semantics

Hmmm: a rude or stupid extension might just always return True.  In my
case, it's the easiest thing to do: how do you know when a database
connection is stale?  Easy answer is to throw it away after each
request cycle.  But forcing localrepository.isstale() to return True
causes unnecessary work at the repository level, when the work should
really only happen at the extension level (open a new database
connection and discard the cache).  That argues for an extension-level
isstale(), a peer of reposetup().  Hmmmmmm.  This requires careful
thought!

Greg