flags: introduce explicit testing for merging change to exec flag It turns out that we do not seems to test the simple case for merging exec flag changes. More advanced case are test (merging exec flag without a common ancestors, merging with a symlink, etc…) but not the basic. We are about introduce various fixes to merging flag change across renames, having the most basic case tested first seems useful. note: We are only testing "adding" an exec flag here, not removing it. We introduce basic test on stable and will consolidate them on default. Differential Revision: https://phab.mercurial-scm.org/D8529

graft-state: save --base in graft's state, fixing bug with graft --continue Without this change, running graft --continue after grafting a merge commit using --base (and encountering conflicts) will output "skipping ungraftable merge revision" even though we specified a base in the initial graft command. Graft's improve behaviour is reflected in test-graft.t. Differential Revision: https://phab.mercurial-scm.org/D8578

setup: raise minimum Python version to 2.7.4 On older Python versions, Mercurial is not really usable because of https://bugs.python.org/issue10211. Recently someone reported a crash on the mailing list when running Mercurial on Python 2.7.3. There was consensus that fixing compatibility for a Python version more than 7 years old is not worth it. So, instead of making Mercurial crash with an obscure exception, this patch raises the minimum Python version to 2.7.4.

fsmonitor: coerce `clock` variable to byte-string (issue6321) Callers of `fsmonitor.state.setlastclock` pass their arguments wrapped in `pycompat.sysbytes` to ensure the value is a `bytes` on Python 3. However in `fsmonitor.poststatus.__call__`, if the return value of `getlastclock()` is `None`, we use the value of `fsmonitor.poststatus._startclock` instead, which is not converted to a byte string in the same manner. This commit converts the value of `startclock` to a byte string using `pycompat.sysbytes` in the constructor for `poststatus`, to avoid the "`str` + `bytes`" error from issue 6321. Differential Revision: https://phab.mercurial-scm.org/D8573

py3: change default priority and length used for sorting hooks to be compatible with python 3 The call to `sorted(hooks.values())` can on line 213 of hooks.py can raise when using python 3. For instance, when hooks.values is `[(0, 2, b'post-commit.check-status', b''), (None, None, b'changegroup.app-hooks', <object object at 0x7f5279885590>)]`, the error is `TypeError: '<' not supported between instances of 'NoneType' and 'int'` This fix keeps the same order that was used in python 2 without relying on comparison with None. Differential Revision: https://phab.mercurial-scm.org/D8527

relnotes: copy "next" to "5.4" and clear "next" This is the same thing as we've done for the previous few releases. Differential Revision: https://phab.mercurial-scm.org/D8546

dirstate: make sure the dirstate is loaded before the changelog (issue6303) Before this change, it was possible for the changelog to be loaded before the dirstate. If a transaction happens betwen the changelog and dirstate reading, the dirstate can up end poitning toward a revision not existing in the (olded) changelog. This lead to a warning. With this revision, we preload the dirstate parent before reading the changelog. This has a negligible performance impact on performance for all case we are tracking. Differential Revision: https://phab.mercurial-scm.org/D8528

rust-dirstatemap: don't read the dirstate when requesting parents A future patch for issue 6303 reveals a big performance regression in the Rust `DirstateMap` that reads the entire dirstate when requesting parents instead of the first 40 bytes. `perfdiscovery` gets a *significant* speedup (from 0.101 to 0.016) when applied against said patch. I'm assuming it has other performance benefits, but this is already a good enough win. Differential Revision: https://phab.mercurial-scm.org/D8513

py3: fix exception in pull when several things happen to a bookmark Specifically, when `changes` is: [(b'@upstream-committed', None, <function ui.status>, b'updating bookmark @upstream-committed\n'), (b'@upstream-committed', binary-node, <function ui.warn>, b'divergent bookmark @ stored as @upstream-committed\n')] sorting the list raises: TypeError: '<' not supported between instances of 'bytes' and 'NoneType' Differential Revision: https://phab.mercurial-scm.org/D8523

fastexport: adjust output to be more canonical For time zones, git doesn't consider +0 and -0 the same timezone, so use the former canonically. Add a test case to ensure that non-UTC offsets are handled correctly. The real name part of the committer name is normally not quoted, so don't enforce that. Differential Revision: https://phab.mercurial-scm.org/D8522

bash_completion: do not use aliased hg if it sources a script (issue6308) I have an alias that sources a script around hg. Mercurial's bash_completion script tries to use this as its main hg binary. But sourcing a wrapper breaks Bash's completion. So this patch disables using the alias as the hg binary if it starts with "source ". Alias resolution was introduced in rev 191ab08e7099 for users with "alias hg='hg --some_opts'". See https://www.mercurial-scm.org/repo/hg/rev/191ab08e7099

demandimport: fix compatibility with meta path finders w/o find_spec() method Meta path finders got a find_spec() method in Python version 3.4. The sys.meta_path documentation says that the deprecated find_module() method is used as a fallback. Setuptool’s VendorImporter still doesn’t have the find_spec() method, which resulted in a crash e.g. within a virtual environment. For reference, I opened an issue for that: https://github.com/pypa/setuptools/issues/2104. An alternative implementation would have been to implement a wrapper for find_module() itself and raise an AttributeError when accessing find_spec() if the wrapped finder doesn’t have it.

tests: fix timer scaling in wait-on-file When using the default test timeouts, wait-on-file would not wait for $n seconds, but $n/100 seconds. This resulted in easy timeouts on even moderately busy fast machines. Fix the scaling to apply in all cases. Adjust the stepping slightly to be nicer to systems with the historic 100Hz time base to ensure that the scheduler actually switches to a different process and gives them time to work. Differential Revision: https://phab.mercurial-scm.org/D8505

manifest-cache: ignore IOError while writing If the wcache directory is non writable for some reason (eg: belong to root). Trying to write to it currently crash Mercurial. Instead we ignore the error and skip writing that cache. We should probably improve the user experience of multiple users interacting with the same repository. However this is not an adventure for stable. Differential Revision: https://phab.mercurial-scm.org/D8512

copy: give better error message when no source paths found with --at-rev The new error message matches what we show when marking copies in the working copy. Differential Revision: https://phab.mercurial-scm.org/D8496

tests: show poor error message for `hg cp -A --at-rev . non-existent dst` Differential Revision: https://phab.mercurial-scm.org/D8495

copy: to find copy source, walk parent of revision we're marking copies in As shown in the previous patch, `hg cp --after --at-rev . src dst` fails if `src` is not in `.`. It seems obvious that you should always walk the *parent* of the revision you're marking copies in, but that's not how it was done for the working copy, and I didn't think to change it when marking copies in a non-working-copy commit. This patch fixes that by walking the parent commit instead, but only if we're marking copies for a non-working-copy commit. We need to leave the working-copy code unchanged because it depends on the weird behavior of `workingctx.walk()`. With these changes, there's very little overlap between the working-copy version and the non-working-copy version of `walkpats()`, but I've refrained from cleaning that up on the stable branch. Differential Revision: https://phab.mercurial-scm.org/D8494

tests: show that `hg cp -A --at-rev .` doesn't work for renames I clearly forgot to implement (and test) support for marking of renames when I added support for marking of copies :( Differential Revision: https://phab.mercurial-scm.org/D8493

formatting: add missing newline Differential Revision: https://phab.mercurial-scm.org/D8509

fastexport: downgrade message about already exported changesets to debug The old warning level is just too noisy for incremental processing. Differential Revision: https://phab.mercurial-scm.org/D8487

url: fix a bytes vs str crash in processing proxy headers (issue6249) I have no idea how to make a test for this, so if somebody knows, feel free to add one or follow up on this. The bug reporter reported that it worked for them, so there may not be other hidden issues here. Differential Revision: https://phab.mercurial-scm.org/D8485

pullbundles: use unfiltered repo for head/base matching The unfiltered view works even when changeset transistion from draft to hidden phase. The normal visibility is already ensured by discovery as invisible heads would have been filtered out before. Skipping the filtering has a positive impact on performance, too. Differential Revision: https://phab.mercurial-scm.org/D8481

procutil: always waiting on child processes to prevent zombies with 'hg serve' When runbgcommand is invoked by an extension with ensurestart=False, we never called waitpid - which is fine in most cases, except if that's happening on a command server (e.g. chg), in which case the child defunct process will just sit there for as long as the server is running. The actual semantics of SIGCHLD signal handling is a lot more complex than it seems, and the POSIX standard *seems* to read that it's ignored by default and everything would just work without the waitpid if we're not listening for it, but the truth is that it's only ignored if we *explicitly* set it to SIG_IGN. We further cannot set it to SIG_IGN or to a catch-all handler across all of 'hg serve', because Python's suprocess.Popen relies on that signal, and a few specific parts of hg also set custom handlers, so instead we wait for specific PIDs in dedicated threads. I did a poor-man's benchmark of the thread creation and it seems to take about 1ms, which is way better than the 20+ms from ensurestart=True. Differential Revision: https://phab.mercurial-scm.org/D8497

tests: use regular POSIX shell wait-on-file requires one POSIX extension (sleep with non-integral argument), but it doesn't require any bash extensions, so just require a normal POSIX shell. While here, use consistent formatting without redundant ; Differential Revision: https://phab.mercurial-scm.org/D8500

rust-regex: increase the DFA size limit for the `regex` crate `re2`'s DFA limit is already increased in `rust/hg-core/src/re2/rust_re2.cpp`, the same has to be done for the `regex` crate. Big repositories with big `.hgignore`s will sometimes hit this limit and face extreme performance regressions (I've seen one take *minutes* for `hg status`). Differential Revision: https://phab.mercurial-scm.org/D8499

Added signature for changeset cf3e07d7648a

Added tag 5.4 for changeset cf3e07d7648a

tests: clarify a comment describing a phabricator test scenario Per review feedback. Differential Revision: https://phab.mercurial-scm.org/D8455