Siddharth Agarwal <sid0@fb.com> [Tue, 22 Sep 2015 16:56:34 -0700] rev 26312
ui: avoid mutable default arguments
I almost introduced a bug around this code by accidentally mutating a default
argument. There's no reason for these to exist.
It is OK to not assign {} to environ in ui.system because util.system knows how
to deal with that.
Siddharth Agarwal <sid0@fb.com> [Tue, 22 Sep 2015 16:55:18 -0700] rev 26311
util: avoid mutable default arguments
I almost introduced a bug around this code by accidentally mutating a default
argument. There's no reason for these to exist.
Yuya Nishihara <yuya@tcha.org> [Sun, 13 Sep 2015 18:01:01 +0900] rev 26310
obsstore: fast path to check if obsstore is empty
Yuya Nishihara <yuya@tcha.org> [Sun, 13 Sep 2015 17:52:37 +0900] rev 26309
obsstore: delay loading markers from obsstore file
This will allow us to use cached revisions without parsing obsstore.
Because _version isn't determined at __init__, the debugobsconvert command no
longer works correctly. I'll fix it by a separate patch for the evolve
extension.
Yuya Nishihara <yuya@tcha.org> [Sun, 13 Sep 2015 17:47:18 +0900] rev 26308
obsstore: initialize _all markers without using _addmarkers()
The next patch will make _all variable propertycached to avoid costly parsing
of obsstore. This means we can't call _addmarkers() to initialize _all.
Because all cached markers depend on _all, it isn't necessary to update these
caches when _all is initially loaded.
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 23 Sep 2015 00:41:07 -0700] rev 26307
revset: avoid implicit None testing in revset
Implicit None testing is a very good way to get in trouble. We explicitly test
for None.
Durham Goode <durham@fb.com> [Sun, 20 Sep 2015 16:53:42 -0700] rev 26306
revset: speed up existence checks for ordered filtered sets
Previously, calling 'if foo:' on a ordered filtered set would start iterating in
whatever the current direction was and return if a value was available. If the
current direction was ascending, but the set had a fastdesc available, this
meant we did a lot more work than necessary.
If this was applied without my previous max/min fixes, it would improve max()
performance (this was my first attempt at fixing the issue). Since those
previous fixes went in though, this doesn't have a visible benefit in the
benchmarks, but it does seem clearly better than it was before so I think it
should still go in.