repair: use context manager for lock management
authorMatt Harbison <matt_harbison@yahoo.com>
Thu, 23 Mar 2017 23:47:23 -0400
changeset 31626 0febf8e4e2ce
parent 31625 c208bc65318a
child 31627 814733e4c02a
repair: use context manager for lock management If repo.lock() raised inside of the try block, 'tr' would have been None in the finally block where it tries to release(). Modernize the syntax instead of just winching the lock out of the try block. I found several other instances of acquiring the lock inside of the 'try', but those finally blocks handle None references. I also started switching some trivial try/finally blocks to context managers, but didn't get them all because indenting over 3x for lock, wlock and transaction would have spilled over 80 characters. That got me wondering if there should be a repo.rwlock(), to handle locking and unlocking in the proper order. It also looks like py27 supports supports multiple context managers for a single 'with' statement. Should I hold off on the rest until py26 is dropped?
mercurial/repair.py
--- a/mercurial/repair.py	Fri Mar 24 19:52:43 2017 -0700
+++ b/mercurial/repair.py	Thu Mar 23 23:47:23 2017 -0400
@@ -214,15 +214,10 @@
 
         for m in updatebm:
             bm[m] = repo[newbmtarget].node()
-        lock = tr = None
-        try:
-            lock = repo.lock()
-            tr = repo.transaction('repair')
-            bm.recordchange(tr)
-            tr.close()
-        finally:
-            tr.release()
-            lock.release()
+
+        with repo.lock():
+            with repo.transaction('repair') as tr:
+                bm.recordchange(tr)
 
         # remove undo files
         for undovfs, undofile in repo.undofiles():