Sun, 12 Apr 2015 14:26:11 -0400 develwarn: handle the end of line inside the function itself
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 12 Apr 2015 14:26:11 -0400] rev 24748
develwarn: handle the end of line inside the function itself The traceback version should not have a end of line at all. The non-traceback version will requires the same things soon.
Sun, 12 Apr 2015 14:24:28 -0400 develwarn: refactor the developer warning logic
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 12 Apr 2015 14:24:28 -0400] rev 24747
develwarn: refactor the developer warning logic The logic is currently duplicated and we plan to make it a bit smarter. So we move it into a function first to make the update more robust and simple.
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...
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip