comparison mercurial/repair.py @ 31626:0febf8e4e2ce

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?
author Matt Harbison <matt_harbison@yahoo.com>
date Thu, 23 Mar 2017 23:47:23 -0400
parents e712a9c35fd8
children 7095e783958d
comparison
equal deleted inserted replaced
31625:c208bc65318a 31626:0febf8e4e2ce
212 f.close() 212 f.close()
213 repo._phasecache.invalidate() 213 repo._phasecache.invalidate()
214 214
215 for m in updatebm: 215 for m in updatebm:
216 bm[m] = repo[newbmtarget].node() 216 bm[m] = repo[newbmtarget].node()
217 lock = tr = None 217
218 try: 218 with repo.lock():
219 lock = repo.lock() 219 with repo.transaction('repair') as tr:
220 tr = repo.transaction('repair') 220 bm.recordchange(tr)
221 bm.recordchange(tr)
222 tr.close()
223 finally:
224 tr.release()
225 lock.release()
226 221
227 # remove undo files 222 # remove undo files
228 for undovfs, undofile in repo.undofiles(): 223 for undovfs, undofile in repo.undofiles():
229 try: 224 try:
230 undovfs.unlink(undofile) 225 undovfs.unlink(undofile)