Sat, 11 Apr 2015 14:44:12 -0400 run-tests: also follow symlink when update PATH with 'run-tests.py' dir
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 11 Apr 2015 14:44:12 -0400] rev 24742
run-tests: also follow symlink when update PATH with 'run-tests.py' dir I'm using 'run-tests.py' from my '$PATH' and use a symlink to get 'run-tests.py' to in that '$PATH'. There is a handful of test helpers (like f) that needs to be in the '$PATH' for the test to run, and they are expected to live next to the 'run-tests.py' binary. Using a symlink confuses this logic, so we add to the '$PATH' both the 'run-tests.py' executable directory, and the actual file location direction.
Sat, 11 Apr 2015 16:55:14 -0400 bundle2: fix names for error part handler
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 11 Apr 2015 16:55:14 -0400] rev 24741
bundle2: fix names for error part handler The name is not very important but copy paste banshee got there. We make distinctive name.
Wed, 15 Apr 2015 11:11:54 -0400 transaction: introduce a transaction ID, to be available to all hooks
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 15 Apr 2015 11:11:54 -0400] rev 24740
transaction: introduce a transaction ID, to be available to all hooks The transaction ID is built from the object ID and creation time stamp to make sure it is unique.
Tue, 14 Apr 2015 13:07:41 -0400 transaction: actually use tr.hookargs in pretxnclose
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 14 Apr 2015 13:07:41 -0400] rev 24739
transaction: actually use tr.hookargs in pretxnclose The 'tr.hookargs' is a dictionary containing all the arguments to be passed to hooks. It is actually used for hooks now...
Sat, 11 Apr 2015 13:58:36 -0400 bundle2: use unbundle source as transaction name
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 11 Apr 2015 13:58:36 -0400] rev 24738
bundle2: use unbundle source as transaction name This is what a bundle 1 push is doing. This got caught by trying to run the whole test-suite using bundle2 for exchanges.
Wed, 15 Apr 2015 18:34:34 -0400 tags: have a different cache file per filter level
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 15 Apr 2015 18:34:34 -0400] rev 24737
tags: have a different cache file per filter level Currently whichever filter level asks for tags last will write the data on disk. This create massive issues when tags are read for "visible" and "unfiltered" on large and multi headed repository (like Mozilla central). See issue4550 for details Each filter level recomputes its own cache without direct collaboration but they all share the same 'hgtagsfnodes' cache. And that is where most of the time is spent.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 +10000 tip