We were previously depending on str() doing something reasonable here,
and we can't depend on the objects in question supporting __bytes__,
so we work around the lack of direct bytes formatting.
We store bytes in exc.args, which should be translated to a byte string
without encode/decode dance.
IOError subclasses are unchanged for now. We'll need to decide how our
IOErrors should be caught.
Here obj.__module__ and obj.__name__ are str. Either we can convert them to
bytes or use an r'' and convert back to bytes when concat is done. I preferred
the later one since we are encoding only once here.
In Python 2:
>>> ls = [4, 2, None]
>>> sorted(ls)
[None, 2, 4]
In Python 3:
>>> ls = [4, 2, None]
>>> sorted(ls)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unorderable types: NoneType() < int()
Therefore we replaced None with -1, and the safe part is that, None and -1 are
only the keys which are used for sorting so we don't need to convert the -1's
back to None.
c01965ab5195 introduced a deterministic `__repr__` for ignores. However, it
didn't account for when ignore was `util.never`. This broke fsmonitor's ignore
change detection -- with an empty hgignore, it would kick in all the time.
Introduce `nevermatcher` and switch to it. This neatly parallels
`alwaysmatcher`.
We raise a more precise subclass of Abort with details about the faulty
version. This will be used to detect this case and display some information
in debugbundle.
The "if visible" guard is now pretty pointless, because the function
call it guards will do almost no work anyway when there are no visible
revisions.
We can also stop wrapping "visible" in a set since it just needs to be
an iterable now.
The pinned revs are simply revisions that should not be hidden even if
hideablerevs() says that should. Let's make that clear by simply
setting "hidden = hideablerevs() - pinnedrevs()" early on.
Roughly speaking, we currently do this to reveal hidden ancestors of
visible revisions:
1. Iterate over all visible non-public revisions and see if they have
hidden parents
2. For each revision found in step (1) walk the chain of hidden
commits and reveal it
We can simplify that by skipping step (1) and doing step (2) from all
visible non-public revisions instead.
This doesn't seem to have much impact on "perfvolatilesets".
Before:
! obsolete
! wall 0.004616 comb 0.000000 user 0.000000 sys 0.000000 (best of 570)
! visible
! wall 0.008235 comb 0.010000 user 0.010000 sys 0.000000 (best of 326)
After:
! obsolete
! wall 0.004727 comb 0.010000 user 0.010000 sys 0.000000 (best of 543)
! visible
! wall 0.008371 comb 0.000000 user 0.000000 sys 0.000000 (best of 324)
Instead of passing the domain into _consistencyblockers() and having
the function calculate the set of revisions to iterate over, let the
caller do it. This is just a minor refactoring to make future changes
simpler.
The function will stop searching as soon as it runs into a non-hidden
revision, so there is no need to restrict by the domain (of mutable
revisions) as well.
This doesn't seem to have much impact on "perfvolatilesets".
Before:
! obsolete
! wall 0.004903 comb 0.000000 user 0.000000 sys 0.000000 (best of 535)
! visible
! wall 0.008913 comb 0.010000 user 0.010000 sys 0.000000 (best of 300)
After:
! obsolete
! wall 0.004616 comb 0.000000 user 0.000000 sys 0.000000 (best of 570)
! visible
! wall 0.008235 comb 0.010000 user 0.010000 sys 0.000000 (best of 326)
This change makes the function actually reveal the ancestors by
removing them from the hidden set. This prepares for further
simplification.
Note that the function will now only reveal contiguous chains of
hidden revisions, but that's fine because we always pass it an
immediate child of any revision that should be revealed (or the
revision itself).
This doesn't seem to have much impact on "perfvolatilesets".
Before:
! obsolete
! wall 0.004672 comb 0.010000 user 0.010000 sys 0.000000 (best of 590)
! visible
! wall 0.008936 comb 0.010000 user 0.010000 sys 0.000000 (best of 322)
After:
! obsolete
! wall 0.004903 comb 0.000000 user 0.000000 sys 0.000000 (best of 535)
! visible
! wall 0.008913 comb 0.010000 user 0.010000 sys 0.000000 (best of 300)
E.g. tags and bookmarks can reveal revisions that would otherwise be
hidden. A revision can also be revealed because one if its descendants
is visible. Let's use the term "pinned" for the former case
(bookmarks etc.).
Prepares for porting to the formatter API. We won't be able to utilize the
abstraction provided by makefilename() because formatter must be instantiated
per file.
To make things simple, openformatter() and maybereopen() have no support
for a plain object API. Callers must use the "with" statement.
Unlike cmdutil.makefileobj(), append mode ('ab') isn't supported by these
functions. This is because JSON output can't be simply concatenated. Perhaps
cmdutil.export() will have to build a {filename: [revs...]} map first and
write revs per file.
Previously `c2` may had an incorrect linkrev because getsrcfctx set wrong
_descendantrev. getsrcfctx() sets descendant rev equals to srcctx.rev() (see
_makegetfctx()), but for `c2` descendant rev should be dstctx. While we were
lucky it didn't broke copytracing it made it significantly slower in some
cases. Besides it broke some external extensions, for example remotefilelog.
Before this change, localrepository instances that performed multiple
transactions would leak transaction objects. This could occur when
running `hg convert`. When running `hg convert`, the leak would be
~90 MB per 10,000 changesets as measured with the Mercurial repo itself.
The leak I tracked down involved the "validate" closure from
localrepository.transaction(). It appeared to be keeping a
reference to the original transaction via __closure__. __del__
semantics and a circular reference involving the repo object
may have also come into play.
Attempting to refactor the "validate" closure proved to be
difficult because the "tr" reference in that closure may
reference an object that isn't created until transaction.__init__
is called. And the "validate" closure is passed as an argument to
transaction.__init__. Plus there is a giant warning comment in
"validate" about how hacky it is. I did not want to venture into
the dragon den.
Anyway, we've had problems with transactions causing leaks before.
The solution then (8b23c334b97f) is the same as the solution in this
patch: drop references to callbacks after they are called. This
not only breaks cycles in core Mercurial but can help break cycles
in extensions that accidentally introduce them.
While I only tracked down a leak due to self.validator, since this is
the 2nd time I've tracked down leaks due to transaction callbacks I
figure enough is enough and we should prevent the class of leak from
occurring regardless of the variable. That's why all callback variables
are now nuked.
This moves the optimization for patterns that match everything to the
caller, so we can remove it from patternmatcher.
Note that we need to teach alwaysmatcher to use relative paths now in
cases like "hg files .." from inside mercurial/, because while it
still matches everything, paths should be printed relative to the
working directory.
By passing in the result of the normalize() call, we prepare for
moving the special handling of patterns that always match out of the
patternmatcher.
It also lets us remove many of the arguments from the matcher, because
they were passed only the the normalize function (we could have
removed the arguments by binding them to the function instead of
moving the normalize() call out).
Since the caller now deals with empty pattern lists, we can drop that
support in the patternmatcher. It now gets the more logical behavior
of matching nothing when no patterns are given (although there is no
in-core caller that will pass no patterns).
In patternmatcher, we used to say that all directories should be
visited if no explicit files were listed, because the case of empty
_files usually implied that no patterns were given (which in turns
meant that everything should match). However, this made e.g. "hg files
-r . rootfilesin:." slower than necessary, because that also ended
up with an empty list in _files. Now that patternmatcher does not
handle includes, the only remaining case where its _files/_fileset
fields will be empty is when it's matching everything. We can
therefore treat the always-case specially and stop treating the empty
_files case specially. This makes the case mentioned above faster on
treemanifest repos.
Having a special matcher that always matches seems to make more sense
than making one of the other matchers handle the case. For now, we
just use this new matcher when no patterns were provided.
Should at least be useful for debugging. Would matter for correctness
too if fsmonitor or Facebook's sparse extension worked with subrepos
(which I don't know if they do).
Due to a quirk of our module importer setup on Python 3, all calls and
definitions of methods named iteritems() get rewritten at import
time. Unfortunately, this means there's not a good portable way to
access these methods from non-module-loader'ed code like our unit
tests. This change fixes that, which also unblocks test-manifest.py
from passing under Python 3.
We don't presently define any itervalues methods, or we'd need to give
those similar treatment.
