changeset 2412:8df32538f662

obshashrangecache: precisely track affected revs when adding new markers This will be useful when we start doing finer grained invalidation (instead of dropping all data).
author Pierre-Yves David <pierre-yves.david@octobus.net>
date Thu, 18 May 2017 17:35:36 +0200
parents bd937b7ce7d2
children 22fb71a2d865
files hgext3rd/evolve/obsdiscovery.py
diffstat 1 files changed, 10 insertions(+), 12 deletions(-) [+]
line wrap: on
line diff
--- a/hgext3rd/evolve/obsdiscovery.py	Thu May 18 14:58:22 2017 +0200
+++ b/hgext3rd/evolve/obsdiscovery.py	Thu May 18 17:35:36 2017 +0200
@@ -491,6 +491,7 @@
         rev = repo.changelog.nodemap.get
         # if we have a new markers affecting a node already covered by the
         # cache, we must abort.
+        affected = set()
         for m in obsmarkers:
             # check successors and parent
             for l in (m[1], m[5]):
@@ -499,18 +500,15 @@
                 for p in l:
                     r = rev(p)
                     if r is not None and r not in setrevs:
-                        repo.ui.log('evoext-cache', 'obshashcache reset - '
-                                    'new markers affect cached ranges\n')
-                        con = self._con
-                        if con is not None:
-                            con.execute(_reset)
-                        break
-                else:
-                    continue
-                break
-            else:
-                continue
-            break
+                        # XXX should check < min(setrevs) or tiprevs
+                        affected.add(r)
+
+        if affected:
+            repo.ui.log('evoext-cache', 'obshashcache reset - '
+                        'new markers affect cached ranges\n')
+            con = self._con
+            if con is not None:
+                con.execute(_reset)
 
         # XXX the current reset is too strong we could just drop the affected range