459366b580cf makes profiler start early without loading extensions. That
makes it impossible for an extension to add customized profilers.
This patch adds a special case: if a profiler is not found but an extension
with the same name could be loaded, load that extension first, and expect it
to have a "profile" contextmanager method. This allows customized profilers
and extension setup time is still profiled.
Exact matchers are only created internally (as opposed to from user
input) based on a set of files that the caller collected before, so
they should always match the list exactly (i.e. case-sensitively).
Now that we have the default-date by default and all code have been updated,
remove the old commands alias that forced the date as they are not longer
useful.
Writing tests now should be easier for everyone now that all dates should be
stable.
In the next patch, I'm gonna removing the global command aliases that force
the epoch date but some tests either fail or their output change after that.
Instead I'm copying the needed aliases in the test files that will otherwise
change.
Update test-rebase-obsolete.t because a revision hash is based on the epoch
date after a 'commit --amend' and the output will change after removing date
aliases.
Update test-subrepo-git.t as the git subrepo doesn't use traditional date
mechanisms. I'm not sure that updating the git subrepo to support default-date
make sense. Add the commit alias to the test in order for making it pass after
removing the date aliases globally.
Also use the default-date when creating obsmarkers. Currently they are created
with the current date and without any option to force their value.
To test the feature, we remove some of the many 'glob' used to match obsmarker
date in the tests.
Add a new config field named default-date under the devel section to force all
implicits date to a specific value. If a explicit date is passed, it will
override the default.
This patch only affect changesets. Other usages (blackbox, obsmarkers) are
updated in later patchs.
The test runner is setting a bunch of alias to force the '--date' argument. We
will replace theses aliases in a later patch.
Split most of util.parsedate in util.rawparsedate and make it raises ValueError instead
of error.Abort.
The util.parsedate function is now just a shell function converting ValueError
to error.Abort for existing users.
I need to parse a date from config in a later patch and use util.rawparsedate
with ui.configwith which expect a convert that raises ValueError.
fsmonitor and debugignore currently access matcher fields that I would
consider implementation details, namely patternspat, includepat, and
excludepat. Let' instead implement __repr__() and have the few users
use that instead.
Marked (API) because the fields can now be None.
Everyone knows that it's supposed to be spelled with two asterisks.
It started failing in 7013de107975 (update: accept --merge to allow
merging across topo branches (issue5125), 2017-02-13) because until
then there was only one argument that was covered by the kwargs, so
*kwargs or **kwargs both worked (or at least that's what I think with
my limited understanding of Python).
revlog.parentrevs() is called while evaluating ^ operator in revsets. When wdir
is passed, it raises IndexError. This patch raises WdirUnsupported if wdir is
passed in the function. The error will be caugth in future patches.
This series intents to support wdir() predicate with different operators
like ~, ^.
Currently the storage class don't support wdir(). This exception is introduced
so that it can be raised from places where wdir() is passed and is not
supported and we can catch this where we want to support the predicate.
Also throwing an error at low level and catching at some higher level is better
than using if-else especially for perf.
match() will soon gain more logic and we don't want to duplicate that
in icasefsmatch(), so merge the two functions instead and use a flag
to get case-insensitive behavior.
On case-insensitive file systems, if file A exists and you try to
remove it (or add, etc.) by specifying a different case, you will see
something like this:
$ hg rm a
removing file A
I honestly found this surprising because it seems to me like it was
explicitly listed by the user. Still, there is a comment in the code
describing it, so it is very clearly intentional. The code was added
in d70aa474bd84 (match: add a subclass for dirstate normalizing of the
matched patterns, 2015-04-12).
I'm going to do a lot of refactoring to matchers and the feature
mentioned above is going to get in my way. I'm therefore removing it
for the time being and we can hopefully add it back when I'm done.
matcher._normalize() no longer depends on any of the matcher's state,
and making it static will enable further refactoring. Note that the
subdirmatcher subclass calls _normalize(), so we can't remove it
completely.
No other arguments are passed via the matcher's state, so we should
treat 'warn' the consistently. More importantly, this will let us make
it a static function, which will help with further refactoring.
The matcher class is getting hard to understand. It will be easier to
follow if we can break it up into simpler matchers that we then
compose. I'm hoping to have one matcher that accepts regular
(non-include) patterns, one for exact file matches, one that always
matches (and maybe one that never does) and then compose them by
intersection and difference.
This patch takes a simple but important step towards that goal by
making match.match() a function (and renaming the matcher class itself
from "match" to "matcher"). The new function will eventually be
responsible for creating the simple matchers and composing them.
icasefsmatcher similarly gets a factory function (called
"icasefsmatch"). I also moved the other factory functions nearby.
In the unlucky case, checklink tries to make a new file for the
symlink test to target. If the filesystem is readonly (perhaps due to
permissions in a repo owned by someone else) we just report the
filesystem as not supporting symlinks, since the user probably can't
write anyway.
RevlogNG is not such a good name when it is no longer the
newest revlog version. Since we'll soon have revlog version 2,
let's remove some references to it.
First, the logic around the if..elif..elif was subtly wrong
and sub-optimal because all branches would be tested as long as
the revlog was valid. This patch changes things so it behaves like
a switch statement over the revlog version.
While I was here, I also tweaked error strings to make them
consistent and to read better.
Loading the obsstore can become a large part of the time necessary to compute
the important volatile set. We add a flag purging all known obsstore related
data.
For example, computing the 'bumped' set currently requires reading the full
obsstore, so timing greatly differ with or without that flag:
Without:
! bumped
! wall 0.005047 comb 0.000000 user 0.000000 sys 0.000000 (best of 446)
With:
! bumped
! wall 0.512367 comb 0.510000 user 0.480000 sys 0.030000 (best of 15)
Receiving markers affecting changeset we'll receives later is legitimate and
not so uncommon case. Working on cache highlighted that this was only testing
in the evolve extension. We add a test for this case in core.
We will soon have matchers that don't have an _always field, so
largefiles needs to stop assuming that they do. _always is only used
by always(), so we safely replace that method instead.
This method is only used internally by destutil, and it's obscure
enough I'm willing to just move it without a deprecation warning,
especially since the new method has more constrained functionality.
Design-wise I'd also like to get active bookmark handling folded into
the bookmark store, so that we don't squirrel away an extra attribute
for the active bookmark on the repository object.
I had to flag some revisions to not undergo check-commit scrutiny
today to get the tests to pass, because they renamed files that had
existing failures which we're not cleaning up. Let's prevent that in
the future by using the extended git diff format to elide moved code.
Adding markers to the repository might affect the set of obsolete changesets. So we
most remove the "volatile" set who rely in that data. We add two missing
invalidations after merging markers. This was caught by code change in the evolve
extensions tests.
This issues highlight that the current way to do things is a bit fragile,
however we keep things simple for stable.
win32mbcs wraps some functions, to prevent them from unintentionally
treating backslash (0x5c), which is used as the second or later byte
of multi bytes characters by problematic encodings, as a path
component delimiter on Windows platform.
This wrapping assumes that wrapped functions can safely accept unicode
string arguments.
Unfortunately, 440868900036 broke this assumption by introducing
pycompat.bytestr() into util.checkwinfilename() for py3 support. After
that, wrapped checkwinfilename() always fails for non-ASCII filename
at pycompat.bytestr() invocation.
This patch wraps underlying pycompat.bytestr() function to use
util.checkwinfilename() safely.
To avoid similar regression in the future, another patch series will
add smoke testing on default branch.
Graft used findmissingrevs to find the candidates for graft duplicates in the
destination. That function operates with the constraint:
1. N is an ancestor of some node in 'heads'
2. N is not an ancestor of any node in 'common'
For our purpose, we do however have to work correctly in cases where the graft
set has multiple roots or where merges between graft ranges are skipped. The
only changesets we can be sure doesn't have ancestors that are grafts of any
changeset in the graftset, are the ones that are common ancestors of *all*
changesets in the graftset. We thus need:
2. N is not an ancestor of all nodes in 'common'
This change will graft more correctly, but it will also in some cases make
graft slower by making it search through a bigger and unnecessary large sets of
changes to find duplicates. In the general case of grafting individual or
linear sets, we do the same amount of work as before.
This demonstrates unfortunate behaviour: extending the graft range cause the
graft to behave differently. When the graft range includes a merge, we fail to
detect duplicates that are ancestors of the merge.
"merge-tools" help topic has described that the merge of the file
fails if no tool is found to merge binary or symlink, since
9da9bced2226 (or Mercurial 1.7), which based on (already removed)
MergeProgram wiki page.
But even at that revision, and of course now, merge of the file
doesn't fail automatically for binary/symlink. ":prompt" (or
equivalent logic) is used, if there is no appropriate tool
configuration for binary/symlink.
As an aside, I'm having trouble parsing the help text meaning for HG when it is
unset or empty. How can it be the frozen name or searched if it is empty?