Sat, 15 Jul 2017 22:42:31 +0200 cachevfs: use the new vfs in when computing branchmap cache
Boris Feld <boris.feld@octobus.net> [Sat, 15 Jul 2017 22:42:31 +0200] rev 33534
cachevfs: use the new vfs in when computing branchmap cache This will help sharing the cache between shares.
Sat, 15 Jul 2017 23:05:04 +0200 cachevfs: add a vfs dedicated to cache
Boris Feld <boris.feld@octobus.net> [Sat, 15 Jul 2017 23:05:04 +0200] rev 33533
cachevfs: add a vfs dedicated to cache Most of the cache content lives in '.hg/cache/'. Moreover they are computed exclusively from data in the '.hg/store' directory. This creates issues with the share extension as the '.hg/store' directory is shared but the '.hg/cache' is not. On large repositories, this makes this prevent some usage of the share extension inefficient as some caches can take minutes to be recomputed. To improve the situation, we introduce a new 'cachevfs' that will be dedicated to cache reading and writing. In the next patches of this series, we'll migrate the 4 existing caches to it and update the share extension.
Sat, 15 Jul 2017 22:40:51 +0200 vfsward: register 'write with no lock' warnings as 'check-locks' config
Boris Feld <boris.feld@octobus.net> [Sat, 15 Jul 2017 22:40:51 +0200] rev 33532
vfsward: register 'write with no lock' warnings as 'check-locks' config Update 'write with no lock' warnings in order to be better controlled by the config. We reuse the option used for lock order for these other lock related message. The message can now be disabled using 'devel.check-locks = no' (in addition to the usual 'devel.all-warnings = no').
Sun, 16 Jul 2017 17:38:39 +0900 demandimport: prefer loaded module over package attribute (issue5617)
Yuya Nishihara <yuya@tcha.org> [Sun, 16 Jul 2017 17:38:39 +0900] rev 33531
demandimport: prefer loaded module over package attribute (issue5617) In general, the attribute of the same name is overwritten by executing an import statement. import a.b print(a.b.c) # 'c' of a/b/__init__.py from a.b.c import d print(a.b.c) # a/b/c.py However, this appears not true for the scenario described in the test case, and surprisingly, "from a.b.c import d" works even if "a.b.c" is not a module. This patch works around the problem by taking the right module from sys.modules if available.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -4 +4 +10 +30 +100 +300 +1000 +3000 +10000 tip