Mercurial > hg
view contrib/tmplrewrite.py @ 17670:9dbd5fa6d301
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.
author | Pierre-Yves David <pierre-yves.david@ens-lyon.org> |
---|---|
date | Mon, 03 Sep 2012 14:03:38 +0200 |
parents | 94ef2c8ce683 |
children |
line wrap: on
line source
#!/usr/bin/python import sys, os, re IGNORE = ['.css', '.py'] oldre = re.compile('#([\w\|%]+)#') def rewrite(fn): f = open(fn) new = open(fn + '.new', 'wb') for ln in f: new.write(oldre.sub('{\\1}', ln)) new.close() f.close() os.rename(new.name, f.name) if __name__ == '__main__': if len(sys.argv) < 2: print 'usage: python tmplrewrite.py [file [file [file]]]' for fn in sys.argv[1:]: if os.path.splitext(fn) in IGNORE: continue print 'rewriting %s...' % fn rewrite(fn)