Mercurial > hg
view hgweb.cgi @ 17670:9dbd5fa6d301
filter: `updatebranchcache` during `addchangegroup` instead of after lock
The forced recomputation of the branch cache was introduced by `ee317dbfb9d0`.
Back there, `addchangegroup` did not handle any lock logic.
Later `ee1ed6afac21` introduced lock logic to `addchangegroup`. Its description
does not explain why the `updatebranchcache` call is made outside locking. I
believe that the lock was released there because it fit well with the transaction
release already in the code.
Finally `926a06f7a353` moved all "unlocked" code of `addchangegroup` to an
`repo._afterlock` callback.
I do not think that the call to `updatebranchcache()` requires to be done
outside locking. That may even be a bad idea to do so. Bringing this call back
in the `addchangegroup` function makes the flow simpler and eases the following
up changelog level filtering business.
author | Pierre-Yves David <pierre-yves.david@ens-lyon.org> |
---|---|
date | Mon, 03 Sep 2012 14:03:38 +0200 |
parents | 85cba926cb59 |
children | 4b0fc75f9403 |
line wrap: on
line source
#!/usr/bin/env python # # An example hgweb CGI script, edit as necessary # See also http://mercurial.selenic.com/wiki/PublishingRepositories # Path to repo or hgweb config to serve (see 'hg help hgweb') config = "/path/to/repo/or/config" # Uncomment and adjust if Mercurial is not installed system-wide # (consult "installed modules" path from 'hg debuginstall'): #import sys; sys.path.insert(0, "/path/to/python/lib") # Uncomment to send python tracebacks to the browser if an error occurs: #import cgitb; cgitb.enable() from mercurial import demandimport; demandimport.enable() from mercurial.hgweb import hgweb, wsgicgi application = hgweb(config) wsgicgi.launch(application)