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.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 +3000 +10000 tip