filter: `updatebranchcache` during `addchangegroup` instead of after lock
authorPierre-Yves David <pierre-yves.david@ens-lyon.org>
Mon, 03 Sep 2012 14:03:38 +0200
changeset 17670 9dbd5fa6d301
parent 17669 405b5f8fdad7
child 17671 fdd0fc046cf1
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.
mercurial/localrepo.py
--- 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)