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)