Siddharth Agarwal <sid0@fb.com> [Mon, 06 Apr 2015 10:46:44 -0700] rev 24624
dirs._addpath: don't mutate Python strings after exposing them (issue4589)
One of the rules of Python strings is that they're immutable. dirs._addpath
breaks this assumption for performance, which is fine as long as it is done
safely -- once a string is no longer internal-only it shouldn't be mutated.
Unfortunately, we weren't being safe here -- we were mutating 'key' even after
adding it to a dictionary.
This only really affects other C code that reads strings, so it's somewhat hard
to write a test for this without poking into the internal representation of the
string via ctypes or similar. There is currently no C code that reads the
output of the string, but there will likely be some soon as the bug indicates.
There's no significant difference in performance.
Bryan O'Sullivan <bryano@fb.com> [Mon, 06 Apr 2015 08:23:27 -0700] rev 24623
parsers: check for memory allocation overflows more carefully
André Sintzoff <andre.sintzoff@gmail.com> [Sat, 04 Apr 2015 11:27:15 +0200] rev 24622
parsers.c: avoid implicit conversion loses integer precision warning
This warning is raised by Apple LLVM version 6.0 (clang-600.0.57)
(based on LLVM 3.5svn) and was introduced in 670aaee7931c
Martin von Zweigbergk <martinvonz@google.com> [Sat, 04 Apr 2015 21:54:12 -0700] rev 24621
dirstate.walk: don't report same file stat multiple times
dirstate.walk() generates pairs of filename and a stat-like
object. After "hg mv foo Foo", it generates one pair for "foo" and one
for "Foo", as it should. However, on case-insensitive file systems,
when it tries to stat to get the disk state as well, it gets the same
stat result for both names. This confuses at least
scmutil._interestingfiles(), making it think that "foo" was forgotten
rather than removed. That, in turn, makes "hg addremove" add "foo"
back, resulting in both cases in the dirstate, as reported in
issue4590.
This change only takes care of the "if unknown" branch. A similar fix
should perhaps be applied to the other branch.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 03 Apr 2015 14:41:18 -0700] rev 24620
repoview: avoid processing the same rev twice in _getstatichidden
If a rev had multiple children, it would be added to the heap multiple times. We
now ensure it is added only once.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 03 Apr 2015 14:37:52 -0700] rev 24619
repoview: skip public parent earlier in _getstatichidden
Public changeset have nothing to offer regarding hidden changeset. Lets not add
them to the heap at all.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 03 Apr 2015 14:36:05 -0700] rev 24618
repoview: directly skip public head in _getstatichidden
Public heads have nothing to offer regarding hidden stuff, let's skip them.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 03 Apr 2015 14:35:53 -0700] rev 24617
repoview: simplify process in _getstatichidden
Since all children are processed before their parents, we can apply the following algorithm:
For each rev (descending order):
* If I'm still hidden, no children will block me,
* If I'm not hidden, I must remove my parent from the hidden set,
This allows us to dynamically change the set of 'hidden' revisions, dropping the
need for the 'actuallyhidden' dictionary and the 'blocked' boolean in the queue.
As before, we start iterating from all heads and stop at the first public
changesets. This ensures the hidden computation is 'O(not public())' instead of
'O(len(min(not public()):))'.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 03 Apr 2015 14:16:50 -0700] rev 24616
repoview: use a heap in _getstatichidden
Since we want to process all non-public changesets from top to bottom, a heap
seems more appropriate. This will ensure any revision is processed after all
its children, opening the way to code simplification.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 03 Apr 2015 13:58:12 -0700] rev 24615
repoview: update documentation of _getstatichidden
In 2f7cb6e6acdd, the function name, role and return was changed. But the
documentation was not. This fixes it.
Yuya Nishihara <yuya@tcha.org> [Sat, 04 Apr 2015 14:56:18 +0900] rev 24614
ssl: resolve symlink before checking for Apple python executable (issue4588)
test-https.t was broken at 07fafcd4bc74 if /usr/bin/pythonX.Y is used on
Mac OS X.
If python executable is not named as "python", run-tests.py creates a symlink
and hghave uses it. On the other hand, the installed hg executable knows the
real path to the system Python. Therefore, there was an inconsistency that
hghave said it was not an Apple python but hg knew it was.
Augie Fackler <augie@google.com> [Fri, 03 Apr 2015 18:19:24 -0400] rev 24613
test-subrepo-recursion: fix output on non-hardlink systems
There's a slight bug present where a topic doesn't get closed when it should.
This isn't a regression, so I've made a note in the test file.
Augie Fackler <augie@google.com> [Fri, 03 Apr 2015 23:12:21 -0400] rev 24612
test-subrepo-recursion: set progress.changedelay really high
This avoids subtopics from showing up, which were introduced by my recent
change that added progress bars to hardlink clones in some cases.
Augie Fackler <augie@google.com> [Fri, 03 Apr 2015 18:10:12 -0400] rev 24611
test-clone: fix test expectations on systems without hardlinks
Siddharth Agarwal <sid0@fb.com> [Wed, 01 Apr 2015 00:44:33 -0700] rev 24610
dirstate: use parsers.make_file_foldmap when available
This is a significant performance win on large repositories. perffilefoldmap:
On Linux/gcc, on a test repo with over 500,000 files:
before: wall 0.605021 comb 0.600000 user 0.560000 sys 0.040000 (best of 17)
after: wall 0.280530 comb 0.280000 user 0.250000 sys 0.030000 (best of 35)
On Mac OS X/clang, on a real-world repo with over 200,000 files:
before: wall 0.281103 comb 0.280000 user 0.260000 sys 0.020000 (best of 34)
after: wall 0.133622 comb 0.140000 user 0.120000 sys 0.020000 (best of 65)
This visibly impacts status times on case-insensitive file systems. On the Mac
OS X repo, status goes from 3.64 seconds to 3.50.
With the third-party hgwatchman extension [1], 'hg status' on the same repo
goes from 0.80 seconds to 0.65.
[1] https://bitbucket.org/facebook/hgwatchman