Wed, 15 Apr 2015 01:20:48 -0400 lock: update the docstring with order information
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 15 Apr 2015 01:20:48 -0400] rev 24746
lock: update the docstring with order information Lock must be acquired in a specific order to avoid dead-lock. This was documented on the wiki, but having this information in the docstring is also useful.
Sun, 12 Apr 2015 13:28:35 -0400 wlock: reword the devel warning
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 12 Apr 2015 13:28:35 -0400] rev 24745
wlock: reword the devel warning We change the wording of the developer warning: - "lock" taken before "wlock" + "wlock" acquired after "lock" The goals here are to: - Put the "subject" as the first word, - use "acquired" instead of "taken" since it seems more accurate.
Sun, 12 Apr 2015 10:01:48 -0400 wlock: only issue devel warning when actually acquiring the lock
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 12 Apr 2015 10:01:48 -0400] rev 24744
wlock: only issue devel warning when actually acquiring the lock Before this change, any call to 'wlock' after we acquired a 'lock' was issuing a warning. This is wrong as the 'wlock' have been properly acquired before the 'lock' in a previous call. We move the warning code to only issue such warnings when we are acquiring the 'wlock' -after- acquiring 'lock'. This is the expected behavior of this warning from the start.
Sat, 11 Apr 2015 17:30:45 -0400 bundle2: flush output in a part in all cases
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 11 Apr 2015 17:30:45 -0400] rev 24743
bundle2: flush output in a part in all cases We want to preserve output even when the unbundling fails (eg: hook output). So we must make sure that everything we have is flushed into the reply bundle. (This is related to issue4594)
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 -10 +10 +100 +300 +1000 +3000 +10000 tip