Gregory Szorc <gregory.szorc@gmail.com> [Sat, 22 Aug 2015 10:37:38 -0700] rev 26068
hghave: remove quiet option
The --quiet flag appears to be unused. Kill it.
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 22 Aug 2015 10:28:34 -0700] rev 26067
hghave: move feature checking into hghave.py
Upcoming patches will kill hghave (the script - not hghave.py) and
will move to a model where requirements checking is performed as
a function call.
Start diminishing the utility of hghave by moving some code to
hghave.py.
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 22 Aug 2015 10:22:12 -0700] rev 26066
tests: move '#require bzr' into .t files
The bzr tests are the only .t tests calling hghave (aside from the tests
testing hghave itself). This pattern is a one-off and prevents
desired refactors to how requirements checking is integrated into tests.
Use the convention used everywhere else.
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 08 Aug 2015 00:12:41 -0700] rev 26065
commands.push: use "pushloc" path attribute
Path instances now have a "pushloc" attribute that exposes the path
to be used for pushing. The "default-push" path is automatically
captured in the "pushloc" attribute of the "default" path.
Drop references to "default-push" and use the "pushloc" attribute
for looking up where to push to.
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 07 Aug 2015 21:53:34 -0700] rev 26064
ui: capture push location on path instances
Currently, we treat "default" and "default-push" as separate paths,
even though they are the same logical entity but with different paths
for different operations. Because they are the same entity and
because we will eventually be implementing an official mechanism
for declaring push URLs for paths, we establish a "pushloc" attribute
on path instances. We populate this attribute on the "default" path
with the "default-push" value, if present. This will enable
consumers stop referencing "default-push" which will make their code
simpler.
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 25 May 2015 13:10:38 -0700] rev 26063
worker: use multiprocessing to find cpu count
The multiprocessing package was added in Python 2.6.
The implementation of worker.countcpus() is very similar to
multiprocessing.cpu_count(). Ditch our one-off code.
multiprocessing does result in a number of imports. However,
the lazy importer ensures that we don't import anything until
cpu_count() is called. Furthermore, if we are doing something
with multiple cores, chances are the time of that operation
will dwarf the import time, so module bloat isn't a concern
here.
Augie Fackler <augie@google.com> [Mon, 24 Aug 2015 10:09:00 -0400] rev 26062
import-checker: ensure multiprocessing is treated as from stdlib
On my linux machines multiprocessing appears to defeat the logic in
import-checker to detect stdlib modules. Since we now only use
versions of Python which ship with multiprocessing, let's just
whitelist the module.
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 20 Aug 2015 17:23:21 -0700] rev 26061
reachableroots: use baseset lazy sorting
smartset sorting is lazy (so faster in some case) and better (informs that the
set is sorted allowing some optimisation). So we rely on it directly.
Some test output are updated because we now have more information (ordering).
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 20 Aug 2015 17:19:56 -0700] rev 26060
baseset: keep the input set around
Baseset needs a list to operate, but will convert that list back to a set for
membership testing. It seems a bit silly to convert the set into a list to
convert it back afterward.
Yuya Nishihara <yuya@tcha.org> [Sun, 16 Aug 2015 09:30:37 +0900] rev 26059
reachableroots: unroll loop that checks if one of parents is reachable
The difference is small, but fewer loops should be better in general:
revset #0: 0::tip
0) 0.001609
1) 0.001510 93%