[PATCH 1 of 8 clfilter-part1] filter: `updatebranchcache` during `addchangegroup` instead of after lock
pierre-yves.david at logilab.fr
pierre-yves.david at logilab.fr
Thu Sep 20 12:12:08 CDT 2012
# HG changeset patch
# User Pierre-Yves David <pierre-yves.david at ens-lyon.org>
# Date 1346673818 -7200
# Node ID 6c1fb5e0f1e814d651b63cd22bfcaeaa2acdad89
# Parent 431e3e827ab08dbb7a40e79af57f271c3928ec07
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.
diff --git a/mercurial/localrepo.py b/mercurial/localrepo.py
--- a/mercurial/localrepo.py
+++ b/mercurial/localrepo.py
@@ -2437,14 +2437,14 @@ class localrepository(object):
cl.finalize(trp)
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)
for n in added:
self.hook("incoming", node=hex(n), source=srctype,
More information about the Mercurial-devel
mailing list