Mercurial > hg
changeset 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 | 405b5f8fdad7 |
| children | fdd0fc046cf1 |
| files | mercurial/localrepo.py |
| diffstat | 1 files changed, 1 insertions(+), 1 deletions(-) [+] |
line wrap: on
line diff
--- a/mercurial/localrepo.py Wed Aug 01 22:13:27 2012 -0500 +++ b/mercurial/localrepo.py Mon Sep 03 14:03:38 2012 +0200 @@ -2439,10 +2439,10 @@ tr.close() if changesets > 0: + self.updatebranchcache() def runhooks(): # forcefully update the on-disk branch cache self.ui.debug("updating the branch cache\n") - self.updatebranchcache() self.hook("changegroup", node=hex(cl.node(clstart)), source=srctype, url=url)