index: use `index.get_rev` in `remotefilelog` Differential Revision: https://phab.mercurial-scm.org/D7357

index: use `index.get_rev` in `histedit.processreplacement` Differential Revision: https://phab.mercurial-scm.org/D7354

index: use `index.get_rev` in `histedit.adjustreplacementsfrommarkers` Differential Revision: https://phab.mercurial-scm.org/D7353

index: use `index.get_rev` in `rebase._computeobsoletenotrebased` Differential Revision: https://phab.mercurial-scm.org/D7350

index: use `index.get_rev` in `rebase.successorrevs` The code is slightly updated in the process for simplicity. Differential Revision: https://phab.mercurial-scm.org/D7349

index: use `index.get_rev` in `unionrepo.unionrevlog` Differential Revision: https://phab.mercurial-scm.org/D7338

index: use `index.rev` in `bundlerepo.bundlerevlog` Differential Revision: https://phab.mercurial-scm.org/D7340

index: use `index.get_rev` in `exchange._pullapplyphases` Differential Revision: https://phab.mercurial-scm.org/D7347

index: use `index.rev` in `exchange.fallbackheads` Differential Revision: https://phab.mercurial-scm.org/D7345

index: use `index.get_rev` in `revset._mapbynodefunc` We slightly update the code in the process. Differential Revision: https://phab.mercurial-scm.org/D7343

index: use `index.get_rev` in `discovery._postprocessobsolete` Differential Revision: https://phab.mercurial-scm.org/D7341

index: use `index.get_rev` in `repoview.pinnedrevs` We simplify the code in the process Differential Revision: https://phab.mercurial-scm.org/D7337

index: use `index.get_rev` in `obsolete._computephasedivergentset` Differential Revision: https://phab.mercurial-scm.org/D7336

index: use `index.get_rev` in `obsutil.getobsoleted` Differential Revision: https://phab.mercurial-scm.org/D7335

index: use `index.get_rev` in `phases.newheads` Differential Revision: https://phab.mercurial-scm.org/D7332

index: use `index.get_rev` in `localrepo.known` Differential Revision: https://phab.mercurial-scm.org/D7327

index: add a `get_rev` method (API) The new `index.getrev(node)` is to be preferred over using: `index.nodemap.get(node)`. This get us closer to be able to remove the `nodemap` attribute of the index. Differential Revision: https://phab.mercurial-scm.org/D7326

index: use `index.rev` in `revlog.rev` Differential Revision: https://phab.mercurial-scm.org/D7325

index: add a `rev` method (API) The new `index.rev(node)` is to be preferred over using `node index.nodemap[node]`. This get us closer to be able to remove the `nodemap` attribute of the index. Differential Revision: https://phab.mercurial-scm.org/D7324

perf: make `perfphasesremote` use the new `index.has_node` api (If available) Differential Revision: https://phab.mercurial-scm.org/D7359

index: use `index.has_node` in `infinitypush` Differential Revision: https://phab.mercurial-scm.org/D7356

index: use `index.has_node` in `phabricator.getoldnodedrevmap` Differential Revision: https://phab.mercurial-scm.org/D7355

index: use `index.has_node` in `histedit.cleanupnode` Differential Revision: https://phab.mercurial-scm.org/D7352

index: use `index.has_node` in `histedit._finishhistedit Differential Revision: https://phab.mercurial-scm.org/D7351

index: use `index.has_node` in `exchangev2._pullchangesetdiscovery` Differential Revision: https://phab.mercurial-scm.org/D7348

index: use `index.has_node` in `exchange._pulldiscoverychangegroup` Differential Revision: https://phab.mercurial-scm.org/D7346

index: use `index.has_node` in `bookmarks.bmstore` Differential Revision: https://phab.mercurial-scm.org/D7344

index: use `index.has_node` in `tags.findglobaltags` Differential Revision: https://phab.mercurial-scm.org/D7342

index: use `index.has_node` in `bundlerepo.bundlerevlog` Differential Revision: https://phab.mercurial-scm.org/D7339

index: use `index.has_node` in `obsutil.foreground` Differential Revision: https://phab.mercurial-scm.org/D7334

index: use `index.has_node` in `obsutil.exclusivemarkers` Differential Revision: https://phab.mercurial-scm.org/D7333

index: use `index.has_node` in `phases.filterunknown` Differential Revision: https://phab.mercurial-scm.org/D7331

index: use `index.has_node` in `analyzeremotephases` Differential Revision: https://phab.mercurial-scm.org/D7330

index: use `index.has_node` in `repo._rollback` Differential Revision: https://phab.mercurial-scm.org/D7329

index: use `index.has_node` in `revlog.addgroup` Differential Revision: https://phab.mercurial-scm.org/D7328

index: use `index.has_node` in `revlog.addrevision` Differential Revision: https://phab.mercurial-scm.org/D7323

index: add a `has_node` method (API) The new `index.has_node(node)` is to be preferred over: `node in index.nodemap`. This get us closer to be able to remove the `nodemap` attribute of the index. Differential Revision: https://phab.mercurial-scm.org/D7322

revlog: deal with nodemap deletion within the index Since the nodemap data now live in the index, it should be the index responsibility to ensure the data are up to date. The C version of the index is already dealing with such deletion. This work is part of a refactoring to unify the revlog index and the nodemap. This unification prepare the use of a persistent nodemap. Differential Revision: https://phab.mercurial-scm.org/D7321

revlog: clean up the node of all revision stripped in the C code For some obscure reason, the loop cleaning up node was skipping the first element… I cannot see a reason for it. The overall code is running fine nevertheless because the node are also explicitly deleted from python. We want to delete this explicit deletion, so we need to fix that code first. This work is part of a refactoring to unify the revlog index and the nodemap. This unification prepare the use of a persistent nodemap. Differential Revision: https://phab.mercurial-scm.org/D7320

revlog: move nodemap update within the index code Since the nodemap data now live in the index, it should be the index responsibility to ensure the data are up to date. This work is part of a refactoring to unify the revlog index and the nodemap. This unification prepare the use of a persistent nodemap. Differential Revision: https://phab.mercurial-scm.org/D7319

revlog: deprecate the _nodecache attribute (API) This attribute have been the same object for a long time. Code should directly access the nodemap in case of need. (Or the final API when this will be done). This work is part of a refactoring to unify the revlog index and the nodemap. This unification prepare the use of a persistent nodemap. Differential Revision: https://phab.mercurial-scm.org/D7318

revlog: access the nodemap through the index The `revlog.rev` method now access the nodemap through `self.index.nodemap`, instead of using the `_nodecache` attribute that we are trying to remove. This work is part of a refactoring to unify the revlog index and the nodemap. This unification prepare the use of a persistent nodemap. Differential Revision: https://phab.mercurial-scm.org/D7317

revlog: return the nodemap as the nodecache Ultimately, the nodecache is the nodemap. To stop having this disctinction, we start using the nodemap where the nodecache was used. This work is part of a refactoring to unify the revlog index and the nodemap. This unification prepare the use of a persistent nodemap. Differential Revision: https://phab.mercurial-scm.org/D7316

revlog: clarify which version use the older API in perf This work is part of a refactoring to unify the revlog index and the nodemap. This unification prepare the use of a persistent nodemap. Differential Revision: https://phab.mercurial-scm.org/D7315

revlog: no longer return the nodemap after parsing Now that both pure and cext version have a `nodemap` attribute, we do not need to return the `nodemap` object after parsing. This work is part of a refactoring to unify the revlog index and the nodemap. This unification prepare the use of a persistent nodemap. Differential Revision: https://phab.mercurial-scm.org/D7314

revlog: move the nodemap into the index object (for pure) This make the pure code closer to the C extension one. The ultimate goal is to merge the two into a single object and offer a unified API. This changeset focus on gathering the data on the same object. For now the code for `revlogoldindex` and `BaseIndexObject` index object are quite similar. However, there will be larger divergence later on, so I don't think is worth doing a base case. This work is part of a refactoring to unify the revlog index and the nodemap. This unification prepare the use of a persistent nodemap. Differential Revision: https://phab.mercurial-scm.org/D7313

revlog: introduce an explicit NodeMap class for pure code This class make the "pure" nodemap raise the same exception than the C-extension one. This is a step toward unifying nodemap and index, the class is not meant to survive on the long run. This work is part of a refactoring to unify the revlog index and the nodemap. This unification prepare the use of a persistent nodemap. There is a new `isinstance` call, it will be cleaned up in coming changesets. Differential Revision: https://phab.mercurial-scm.org/D7312

utils: move the `dirs` definition in pathutil (API) Before this change, the `dirs` class was accessible through the `mercurial.util` module. That module is expected to stay free of scm specific content. The `pathutil` destination has been selection by Martin von Zweigbergk. This work is part of a refactoring to unify the revlog index and the nodemap. This unification prepare the use of a persistent nodemap. Differential Revision: https://phab.mercurial-scm.org/D7311

packaging: stop installing i18n files The WiX installer has been shipping the content of the i18n/ directory since it was introduced in 2010 in 1e022c88a0a5. And the installer was subsequently refactored to only ship the .po files and hggettext. The .po files and the hggettext script are only used at build time to produce .mo files, which Mercurial does use at run-time. It doesn't make sense to install these files on Windows. So this commit stops doing that. This change further converges the file layout of the Inno and WiX installers. Differential Revision: https://phab.mercurial-scm.org/D7165

packaging: install hgk as hgk.tcl Giving it a file extension will give Windows a better chance at being able to execute it via standard means. This also makes WiX consistent with the Inno installer. Differential Revision: https://phab.mercurial-scm.org/D7164

packaging: add logo-droplets.svg The WiX installer adds this file. Let's add it to the Inno installer for consistency. Differential Revision: https://phab.mercurial-scm.org/D7163

packaging: install documentation to doc/ directory The source directory is "doc" and "doc" is used by the WiX installer. I think it makes sense to converge on the canonical path name. While we're here, we also lower the case because we can. (I think lower case names make more sense plus it is more consistent.) This only affects the Inno installer at the moment because it is the only installer using the staging code. Differential Revision: https://phab.mercurial-scm.org/D7162

packaging: always pass VERSION into Inno invocation The code in the Inno file was a holdover from before we had Python driving execution. With Python in the driver's seat, we can now have it resolve the version string and pass it into Inno, making the code easier to understand for people who aren't packaging gurus. Differential Revision: https://phab.mercurial-scm.org/D7161

packaging: remove hg.exe.local file <exe>.local files are used by Windows to set up DLL redirection. But these files are ignored if you embed an application manifest in your binary, which we do. So the existence of this file serves no purpose. So we remove it. Differential Revision: https://phab.mercurial-scm.org/D7160

packaging: stage installed files for Inno Previously, the Inno installer maintained its own mapping of source files to install location. (We have to maintain a similar mapping in the WiX installer.) Managing the explicit file layout for Windows packages is cumbersome and redundant. Every time you want to change the layout you need to change N locations. We frequently forget to do this and we only find out when people install Mercurial from our packages at release time. This commit starts the process of consolidating and simplifying the logic for managing the install layout on Windows. We introduce a list of install layout rules. These are simply source filenames (which can contain wildcards) and destination paths. The Inno packaging code has been updated to assemble all files into a staging directory that mirrors the final install layout. The list of files to add to the installer is derived by walking this staging directory and dynamically emitting the proper entries for the Inno Setup script. I diffed the file layout before and after this commit and there is no difference. Another benefit of this change is that it facilitates easier testing of the Windows install layout. Before, in order to test the final install layout, you needed to build an installer and run it. Now, you can stage files into the final layout and test from there, without running the installer. This should cut down on overhead when changing Windows code. Differential Revision: https://phab.mercurial-scm.org/D7159

packaging: process Inno Setup files with Jinja2 I want to make the Inno Setup files dynamically generated. This will enable us to do things like automatically derive the set of files to be packaged instead of having to manually keep lists of files in sync across installers. As the first step towards this, we process the Inno Setup files with Jinja2. As part of this conversion, we had to escape syntax in mercurial.iss that conflicts with Jinja2. I also took the opportunity to include modpath.iss via Jinja2 instead of using Inno's preprocessor. This keeps the Python code a bit simpler. Differential Revision: https://phab.mercurial-scm.org/D7158

packaging: install and run Inno files in a build directory Upcoming commits will refactor the Windows installers so their content is dynamically derived. In preparation for this, we copy the Inno files into a new build directory and run them from there. This required changing some relative paths to work from a new directory level but is otherwise a pretty straightforward change. Differential Revision: https://phab.mercurial-scm.org/D7157

packaging: consolidate CLI functionality into packaging.py Consolidating functionality for invoking code in the hgpackaging package through a single CLI entry point will make things simpler when we add more complexity to that package. For example, it will allow us to run things out of a virtualenv with third party packages. This commit consolidates functionality from the Inno and WiX build.py scripts into a new packaging.py script. That script simply creates a virtualenv and runs the CLI functionality in it. The new virtualenv is populated with jinja2 because I felt it easier to incorporate requirements file processing in this commit and we will soon use jinja2 in an upcoming commit. The unified CLI functionality will also make it easier to script other packaging workflows going forward. e.g. RPM, Debian, and macOS packaging. Differential Revision: https://phab.mercurial-scm.org/D7156

packaging: clean up excess packages for Inno This partially reverts e97ffa5511ba. A bunch of package dependencies were getting picked up because I ran pip-compile on Linux and the keyring package has some Linux-only dependencies. I have run pip-compile again - this time from Windows - to undo the addition of these dependencies. I also normalized whitespace to LF. Differential Revision: https://phab.mercurial-scm.org/D7155

unshelve: correct help string; unshelve does not accept file list The non-option arguments to `hg unshelve` are interpreted as the name of the shelve to unshelve, not the list of files to unshelve. While that functionality would probably be nice to have, that's well beyond the scope of this documentation fix. Differential Revision: https://phab.mercurial-scm.org/D7365

repoview: use class literal for creating filteredchangelog The type name is constant, so we don't need to create it dynamically using type(). As suggested by Yuya. Differential Revision: https://phab.mercurial-scm.org/D7364

vagrant: update vagrant image to buster from jessie I honestly have no idea if this works since I don't use vagrant, but looking around online suggests it should work fine. Differential Revision: https://phab.mercurial-scm.org/D7309

packaging: remove references to debian jessie Jessie is on life support at this point, so let's update the list of releases in the Makefiles. Differential Revision: https://phab.mercurial-scm.org/D7308

sqlitestore: remove superfluous r-prefixes on strings I did this file separately because it's a _ton_ of hits and it had some manual reformatting fallout as a result of black squeezing some expressions onto a single line. Differential Revision: https://phab.mercurial-scm.org/D7307

cleanup: remove pointless r-prefixes on single-quoted strings This is the promised second step on single-quoted strings. These had existed because our source transformer didn't turn r'' into b'', so we had tagged some strings as r-strings to get "native" strings on both Pythons. Now that the transformer is gone, we can dispense with this nonsense. Methodology: I ran hg locate 'set:added() or modified() or clean()' | egrep '.*\.py$' | xargs egrep --color=never -n -- \[\^b\]\[\^a-z\]r\'\[\^\'\\\\\]\*\'\[\^\'\ in an emacs grep-mode buffer, and then used a keyboard macro to iterate over the results and remove the r prefix as needed. # skip-blame removing unneeded r prefixes left over from Python 3 migration. Differential Revision: https://phab.mercurial-scm.org/D7306

rust-threads: force Rayon to respect the worker count in config As per the inline comment, this is a workaround because Rust code does not yet know how to read config files. Differential Revision: https://phab.mercurial-scm.org/D7310

phabricator: use context manager form of progress in uploadchunks Follow-up to 453079605242 / D7046. Differential Revision: https://phab.mercurial-scm.org/D7134

cleanup: remove pointless r-prefixes on double-quoted strings This is only double-quoted strings. I'll do single-quoted strings as a second step. These had existed because our source transformer didn't turn r"" into b"", so we had tagged some strings as r-strings to get "native" strings on both Pythons. Now that the transformer is gone, we can dispense with this nonsense. Methodology: I ran hg locate 'set:added() or modified() or clean()' | egrep '.*\.py$' | xargs egrep --color=never -n -- \[\^a-z\]r\"\[\^\"\\\\\]\*\"\[\^\"\] in an emacs grep-mode buffer, and then used a keyboard macro to iterate over the results and remove the r prefix as needed. # skip-blame removing unneeded r prefixes left over from Python 3 migration. Differential Revision: https://phab.mercurial-scm.org/D7305

formatting: remove another data-ogre from the config example The fix extension will pass the contents on stdin and read the output from stdout. By invoking `rustfmt` as `rustfmt {rootpath}`, we tell rustfmt to format the given path and update it on disk. That also makes rustftm not produce the formatted output to stdout. So the fix extension ends up writing out empty files. Differential Revision: https://phab.mercurial-scm.org/D7304

fix: replace str() by b'%d' for formatting integer Differential Revision: https://phab.mercurial-scm.org/D7303

zeroconf: improve the extension's documentation Differential Revision: https://phab.mercurial-scm.org/D7302

branchmap: pytype is confused about bytestr Differential Revision: https://phab.mercurial-scm.org/D7290

mail: suppress a pytype error that's just experimentally wrong It's probably more correct to pass a str here, but I'm not going to worry about it for now. Differential Revision: https://phab.mercurial-scm.org/D7283

dagparser: suppress some pytype errors around pycompat.bytestring I can't justify why we're getting these errors, but nothing I do fixes these handful of calls, so let's just move on with suppressions. Differential Revision: https://phab.mercurial-scm.org/D7277

encoding: add comment-based type hints for pytype Differential Revision: https://phab.mercurial-scm.org/D7275

merge with stable

dirs: reject consecutive slashes in paths We shouldn't ever see those, and the fuzzer go really excited that if it gives us a 65k string with 55k slashes in it we use a lot of RAM. This is a better fix than what I tried in D7105. It was suggested by Yuya, and I verified it does in fact cause the fuzzer to not OOM. This is a revision of D7234, but with the missing set of an error added. I added a unit test of the dirs behavior because I needed to reason more carefully about the failure modes around consecutive slashes. Differential Revision: https://phab.mercurial-scm.org/D7252

tests: quote $PYTHON in test-byteify-strings.t This is needed because the default install location is "Program Files" on Windows. Differential Revision: https://phab.mercurial-scm.org/D7251

repoview: define filteredchangelog as a top-level (non-local) class As suggested by Greg. This makes it easier for extensions to override the filtering. Differential Revision: https://phab.mercurial-scm.org/D7256

cmdutil: suppress bogus pytype errors pytype seems to handle our subclass of tuple (scmutil.status) especially poorly. We should probably file a bug. Differential Revision: https://phab.mercurial-scm.org/D7294

changegroup: suppress pytype error that's wrong Differential Revision: https://phab.mercurial-scm.org/D7293

changegroup: avoid shadowing a set with an int This confuses the heck out of pytype, and I basically agree with it that this shadowing is confusing. There's a chance this causes some memory to be freed later, but I think it's probably not worth worrying about for now. Differential Revision: https://phab.mercurial-scm.org/D7292

bundle2: more pytype suppressions around bytestring We clearly need to work around this somehow. Differential Revision: https://phab.mercurial-scm.org/D7291

archival: suppress some incorrect pytype failures Again, I suspect some missing coverage in type stubs for the stdlib. I'll revisit these later. Differential Revision: https://phab.mercurial-scm.org/D7288

simplemerge: disable a pytype error where it's just confused Differential Revision: https://phab.mercurial-scm.org/D7287

match: suppress error about subscripting an exception I get the sense I should file a bug about subscripting Exception subclasses. Differential Revision: https://phab.mercurial-scm.org/D7286

vfs: more attribute suppressions Differential Revision: https://phab.mercurial-scm.org/D7285

mdiff: mark diffopts as having dynamic attributes This class looks like we could move it to being an attrs and life would be better, but let's do that later. Differential Revision: https://phab.mercurial-scm.org/D7284

vfs: suppress some pytype errors around us using a private attribute Looking at threading._MainThread seems like we're probably a little unsupported, but since this code appears to work on both Python 2 and 3 I'm not going to sweat this for now. Differential Revision: https://phab.mercurial-scm.org/D7282

wireprototypes: disable pytype where it's just confused By inspection validnames is always a Set[bytes] here, but for some reason pytype is convinced it's a bytes. Let's disable the error for now. Differential Revision: https://phab.mercurial-scm.org/D7281

scmposix: another suppression on IOError subscripting As before, this will clear up when we move to Python 3-only. Differential Revision: https://phab.mercurial-scm.org/D7280

pvec: add an explicit type hint to help pytype Differential Revision: https://phab.mercurial-scm.org/D7279

procutil: suppress pytype warnings around windows-only attributes Differential Revision: https://phab.mercurial-scm.org/D7278

posix: add a pytype suppression This one seems a little sketchier than the others, but this will clean up when we're Python 3-only. Differential Revision: https://phab.mercurial-scm.org/D7276

color: suppress pytype warning on a windows-only module Differential Revision: https://phab.mercurial-scm.org/D7274

compression: tell pytype to not sweat a missing `zstd` module Differential Revision: https://phab.mercurial-scm.org/D7273

pytype: don't warn us about ignored-on-py3 metaclasses We can remove this when we're Python 3-only, but for now it's just too awkward to deal with and it's harmless. Differential Revision: https://phab.mercurial-scm.org/D7272

linelog: be more careful about types before looking for _target attribute Without this, pytype (correctly) complains that fakejge might not have a _cmprev attribute. We're operating on some constraints not expressible in the type system, so we detect the invalid case and raise a nicer exception now. Sadly, we also need an `assert` to give PyType a clue that we know what we're doing, but I can absolutely live with that. Differential Revision: https://phab.mercurial-scm.org/D7271

linelog: suppress annoying pytype warning about an ignored metaclass This isn't actively hurting us right now, and it's not trivial to set up this metaclass correctly on both Python 2 and Python 3 without dragging in all of `six`, but we still get lots of typechecking goodness with this error suppressed. Differential Revision: https://phab.mercurial-scm.org/D7270

hgignore: ignore generated pytype stubs Differential Revision: https://phab.mercurial-scm.org/D7269

hghave: add a check for pytype, Google's Python type checker I'm not unbiased, but I strongly prefer pytype to mypy: it does more inference, so we don't need as many annontations. In theory we can use both, but since I'm doing some tinkering with pytype I figured I'd just try setting it up. Differential Revision: https://phab.mercurial-scm.org/D7268

encoding: define local identify functions with explicit type comments This removes some obfuscation as far as pytype is concerned and corrects many bogus type errors. Differential Revision: https://phab.mercurial-scm.org/D7267

vfs: add NotImplementedError version of join Again, this helps out pytype. Differential Revision: https://phab.mercurial-scm.org/D7266

vfs: add a NotImplementedError implementation of __call__ This helps pytype considerably on this file. Differential Revision: https://phab.mercurial-scm.org/D7265

vfs: fix erroneous bytes constants Detected with pytype. Differential Revision: https://phab.mercurial-scm.org/D7264

pvec: migrate to modern integer division Detected with pytype. Differential Revision: https://phab.mercurial-scm.org/D7263

templateutil: fix a missing ABCMeta assignment Caught by pytype. Differential Revision: https://phab.mercurial-scm.org/D7262

pvec: fix overlooked chr() call Caught by pytype. Differential Revision: https://phab.mercurial-scm.org/D7261

vfs: another bytes-str confusion on thread name Differential Revision: https://phab.mercurial-scm.org/D7260

statprof: correctly always pass a str as the thread name Caught by pytype. Differential Revision: https://phab.mercurial-scm.org/D7259

py3: fix handling of ctrl keys in crecord (issue6213) The "keypressed" value in handlekeypressed() is a key name obtained by curses's getkey(); this can be a multibyte string for special keys like CTRL keys. Calling curses.unctrl() with such a value fails on Python 3 with a TypeError as described in issue6213. (On Python 2, this does not crash, but I'm not sure the result is correct, though it does no matter here.) So instead of calling unctrl(), we compare "keypressed" with the expected "^L" obtained by curses.ascii.ctrl("L").

py3: keep "keypressed" a native str in crecord This will help in the next changeset by avoiding a decode step. Also, the actual bytes conversion seems superfluous since values coming from curses's getkey() will be a native string. As a consequence, we open the "testcommands" file (used in test-interactive-curses.t) in text mode.

py3: compare response of crecord's confirmationwindow with str confirmationwindow() returns a native string, as a result of calling chr() on getch(). On Python 3, response.lower().startswith(b"y") leads to a TypeError. This fixes a crash when typing "r" in the curses interface of interactive commit.

py3: compare http server's command with a native string The "command" attribute is an str, so comparing with a bytes would not work on Python 3. This might solve issues in test-lfs-serve-access.t that happens sometimes (especially in CI): --- /hgwork/src/tests/test-lfs-serve-access.t +++ /hgwork/src/tests/test-lfs-serve-access.t.err @@ -163,11 +163,13 @@ $ cat $TESTTMP/access.log $TESTTMP/errors.log $LOCALIP - - [$LOGDATE$] "POST /missing/objects/batch HTTP/1.1" 404 - (glob) + $LOCALIP - - [05/Nov/2019 16:32:34] "{"objects": [{"oid": "f03217a32529a28a42d03b1244fe09b6e0f9fd06d7b966d4d50567be2abe6c0e", "size": 20}], "operation": "download"}" HTTPStatus.BAD_REQUEST - $LOCALIP - - [$LOGDATE$] "GET /subdir/mount/point?cmd=capabilities HTTP/1.1" 200 - (glob) $LOCALIP - - [$LOGDATE$] "GET /subdir/mount/point?cmd=batch HTTP/1.1" 200 - x-hgarg-1:cmds=heads+%3Bknown+nodes%3D x-hgproto-1:0.1 0.2 comp=$USUAL_COMPRESSIONS$ partial-pull (glob) $LOCALIP - - [$LOGDATE$] "GET /subdir/mount/point?cmd=getbundle HTTP/1.1" 200 - x-hgarg-1:bookmarks=1&bundlecaps=HG20%2Cbundle2%3DHG20%250Abookmarks%250Achangegroup%253D01%252C02%252C03%250Adigests%253Dmd5%252Csha1%252Csha512%250Aerror%253Dabort%252Cunsupportedcontent%252Cpushraced%252Cpushkey%250Ahgtagsfnodes%250Alistkeys%250Aphases%253Dheads%250Apushkey%250Aremote-changegroup%253Dhttp%252Chttps%250Arev-branch-cache%250Astream%253Dv2&cg=1&common=0000000000000000000000000000000000000000&heads=525251863cad618e55d483555f3d00a2ca99597e&listkeys=bookmarks&phases=1 x-hgproto-1:0.1 0.2 comp=$USUAL_COMPRESSIONS$ partial-pull (glob) $LOCALIP - - [$LOGDATE$] "POST /subdir/mount/point/.git/info/lfs/objects/batch HTTP/1.1" 200 - (glob) $LOCALIP - - [$LOGDATE$] "GET /subdir/mount/point/.hg/lfs/objects/f03217a32529a28a42d03b1244fe09b6e0f9fd06d7b966d4d50567be2abe6c0e HTTP/1.1" 200 - (glob) + $LOCALIP - - [05/Nov/2019 16:32:34] code 400, message Bad request version ('"download"}') Blobs that already exist in the usercache are linked into the repo store, even though the client doesn't send the blob. @@ -195,6 +197,7 @@ server2/.hg/store/lfs/objects/f0/3217a32529a28a42d03b1244fe09b6e0f9fd06d7b966d4d50567be2abe6c0e $ "$PYTHON" $RUNTESTDIR/killdaemons.py $DAEMON_PIDS $ cat $TESTTMP/errors.log + $LOCALIP - - [05/Nov/2019 16:32:34] code 400, message Bad request version ('"download"}') $ cat >> $TESTTMP/lfsstoreerror.py <<EOF > import errno (from https://ci.hg.gregoryszorc.com/job-info/hg-committed-ca3dca416f8d5863ca6f5a4a6a6bb835dcd5feeb-debian10-cpython-3.7-0)

rust-status: remove dead code The `walk_explicit` function is only called when using a prefix matcher, which the Rust code does not yet support. This function will return in a future patch, probably with a different signature for performance reasons. With it, the `files` argument and its interface code can be removed for now. Differential Revision: https://phab.mercurial-scm.org/D7253

hghave: disallow symlinks on Windows Symlinks on Windows require either a special priviledge, or enabling Developer Mode. It's probably the latter that is enabled on the new CI machine. But since Mercurial itself is saying no to symlinks on Windows, the tests for symlinks shouldn't be attempted. This should fix a lot of the noise in the py3 tests. Differential Revision: https://phab.mercurial-scm.org/D7233

repoview: avoid wrapping changelog if there's nothing to filter This simplifies the code a bit by moving the optimizaton for no filtered revisions to one place. I assume it also makes working with repos without obsmarkers a little faster, but it doesn't seem significant. Differential Revision: https://phab.mercurial-scm.org/D7248

repoview: move changelog.flags() override to filteredchangelog Differential Revision: https://phab.mercurial-scm.org/D7247

repoview: move changelog.parentrevs() override to filteredchangelog Differential Revision: https://phab.mercurial-scm.org/D7246

repoview: move changelog.linkrev() override to filteredchangelog Differential Revision: https://phab.mercurial-scm.org/D7245

repoview: move changelog.node() override to filteredchangelog Differential Revision: https://phab.mercurial-scm.org/D7244

repoview: move changelog.rev() override to filteredchangelog Differential Revision: https://phab.mercurial-scm.org/D7243

repoview: move changelog.strip() override to filteredchangelog Differential Revision: https://phab.mercurial-scm.org/D7242

repoview: move changelog.headrevs() override to filteredchangelog Differential Revision: https://phab.mercurial-scm.org/D7241

repoview: move changelog.revs() override to filteredchangelog Differential Revision: https://phab.mercurial-scm.org/D7240

repoview: move changelog.__iter__() override to filteredchangelog Differential Revision: https://phab.mercurial-scm.org/D7239

repoview: move changelog.__contains__() override to filteredchangelog Differential Revision: https://phab.mercurial-scm.org/D7238

repoview: move changelog.tiprev() override to filteredchangelog Differential Revision: https://phab.mercurial-scm.org/D7237

repoview: wrap changelog class when filtering The class doesn't yet do anything. I'll move the filter-aware overrides from the changelog class over one by one to this class in coming patches. That will leave the changelog class simpler and will centralize more of the filtering logic to repoview. I could not measure any performance difference. Differential Revision: https://phab.mercurial-scm.org/D7236

repoview: extract a function for wrapping changelog I would like to clean up the changelog class by moving out knowledge of filtering. The filtering will instead be done in a class that wraps the changelog. This patch prepares for that. Differential Revision: https://phab.mercurial-scm.org/D7235

revlog: move tiprev() from changelog up to revlog This makes the changelog override simpler and it seems more consistent. Differential Revision: https://phab.mercurial-scm.org/D7250

tests: fix a few `(no-windows !)` conditionals that are really `(symlink !)` The CI for py3 is assuming that symlinks are possible (they are when running as Administrator or when Developer Mode is enabled), and these popped up. Differential Revision: https://phab.mercurial-scm.org/D7232

rust-matchers: add `Matcher` trait and implement `AlwaysMatcher` In our quest of a faster Mercurial, we have arrived at the point where we need to implement the matchers in Rust. This RFC mainly for the `Matcher` trait to see if the changes proposed feel fine to people with more experience on the matter. While the `AlwaysMatcher` implementation is here as a trivial example, it should be the first step towards matchers use in Rust as it is currently the only supported one. Notable changes: - `exact` is renamed to `exact_match` - enums for `visit*` methods with `Recursive` instead of `'all'`, etc. - a new `roots`, separate from `file_set` - no `bad`, `explicitdir` or `traversedir` functions as they can be passed to the high functions instead of the matchers Thanks to Martin for suggesting the last two (most important) changes and for reaching out to help a few weeks ago. Differential Revision: https://phab.mercurial-scm.org/D7178

merge with stable

perf: add a way to benchmark `dirstate.status` Getting more details about time spend in this specific internal bit is meaningful.

largefiles: delete obsolete and unused repo.push() The function was removed from localrepo in 4d52e6eb98ea (locarepo: remove the `push` method (API), 2014-09-25). Differential Revision: https://phab.mercurial-scm.org/D7174

censor: document that some commands simply ignore censored data I can't see a benefit for hg grep to ever error out early when it encounters censored data.

grep: warn on censored revisions instead of erroring out We need most of the grep logic to go through in case we encounter a censored revision, so we just return a None body for a censored node, and we stop just short of trying to record matches with the contents of that censored body. The other parts such as recording that the censored file has been considered at this revision needs to go into the proper dicts. I have also gotten weary of all the abbreviations, so while I did a small refactor to move the file-data-getting operation into a common function, I also expanded the abbreviations of the relevant variables within this little function. Hopefully some day this helps someone figure out what all the abbreviations mean. Although the censoring docs currently state that some commands error out or are ignored depending on the `censor.policy` config, I cannot see a benefit for grep to ever stop dead in its tracks when a censored revision is encountered. I will also amend the docs to indicate that some commands, such as grep, unconditionally ignore censored revisions.

py3: enable legacy fs encoding to fix filename compatibility on Windows This patch is untested. I just followed the instruction: https://docs.python.org/3/whatsnew/3.6.html#pep-529-change-windows-filesystem-encoding-to-utf-8

rust-cpython: run cargo fmt

rust-cpython: remove useless PyResult<> from leak_immutable() The caller should know if the shared data is mutably borrowed or not.

rust-cpython: remove useless PyRefMut wrapper

rust-cpython: drop manual management of mutably_borrowed RefCell::borrow() should guarantee there's no mutable borrow. As a follow up, maybe PySharedState can be a pure data structure + function. Most ref-sharing business has already been moved to PySharedRef* and PyLeaked*.

rust-cpython: leverage RefCell::borrow() to guarantee there's no mutable ref Since the underlying value can't be mutably borrowed by PyLeaked, we don't have to manage yet another mutably-borrowed state. We can just rely on the RefCell implementation. Maybe we can add try_leak_immutable(), but this patch doesn't in order to keep the patch series not too long.

rust-cpython: remove useless Option<$leaked> from py_shared_iterator We no longer need to carefully drop the iterator when it's consumed. Mutation is allowed even if the iterator exists. There's a minor behavior change: next(iter) may return/raise something other than StopIteration if it's called after the iterator has been fully consumed, and if the Rust object isn't a FusedIterator.

rust-cpython: allow mutation unless leaked reference is borrowed In other words, mutation is allowed while a Python iterator holding PyLeaked exists. The iterator will be invalidated instead. We still need a borrow_count to prevent mutation while leaked data is dereferenced in Rust world, but most leak_count business is superseded by the generation counter. decrease_leak_count(py, true) will be removed soon.

rust-cpython: add generation counter to leaked reference This counter increments on borrow_mut() to invalidate existing leaked references. This is modeled after the iterator invalidation in Python. The other checks will be adjusted by the subsequent patches.

rust-cpython: add stub wrapper that'll prevent leaked data from being mutated In order to allow mutation of PySharedRefCell value while PyLeaked reference exists, we need yet another "borrow" scope where mutation is prohibited. try_borrow<'a> and try_borrow_mut<'a> defines the "borrow" scope <'a>. The subsequent patches will implement leak counter based on this scope. PyLeakedRef<T> and PyLeakedRefMut<T> could be unified to PyLeakedRef<&T> and PyLeakedRef<&mut T> respectively, but I didn't do that since it seemed a bit weird that deref_mut() would return a mutable reference to an immutable reference.

rust-cpython: rename PyLeakedRef to PyLeaked This series will make PyLeaked* behave more like a Python iterator, which means mutation of the owner object will be allowed and the leaked reference (i.e. the iterator) will be invalidated instead. I'll add PyLeakedRef/PyLeakedRefMut structs which will represent a "borrowed" state, and prevent the underlying value from being mutably borrowed while the leaked reference is in use: let shared = self.inner_shared(py); let leaked = shared.leak_immutable(); { let leaked_ref: PyLeakedRef<_> = leaked.borrow(py); shared.borrow_mut(); // panics since the underlying value is borrowed } shared.borrow_mut(); // allowed The relation between PyLeaked* structs is quite similar to RefCell/Ref/RefMut, but the implementation can't be reused because the borrowing state will have to be shared across objects having no lifetime relation. PyLeaked isn't named as PyLeakedCell since it isn't actually a cell in that leaked.borrow_mut() will require &mut self.

py3: don't use bytes with vars() or __dict__ Inspired by D7227. These were all the remaining instances I could find. Differential Revision: https://phab.mercurial-scm.org/D7230

Added signature for changeset ca3dca416f8d

Added tag 5.2 for changeset ca3dca416f8d

py3: add inline comment about encoding issue of str(Abort())

py3: do not reimplement Abort.__str__() on Python 2 It isn't necessary on Python 2, and the default implementation should be better than our BaseException_str() clone.

tests: write out file using bytes I/O The encoding of sys.stdout varies between Python versions. So using a one-liner to write a file from a Unicode string is not deterministic. This commit writes out the file using bytes I/O to ensure we have exactly the bytes we want in the file. This change fixes a test failure in Python 3.5/3.6. Differential Revision: https://phab.mercurial-scm.org/D7226

import-checker: open all source files as utf-8 Before, we opened in text mode and used the default encoding to interpret the bytes within. This caused problems interpreting some byte sequences in some files. This commit changes things to always open files as UTF-8, which makes the error go away. test-check-module-imports.t now passes on Python 3.5 and 3.6 with this change. Differential Revision: https://phab.mercurial-scm.org/D7225

localrepo: use str for lookup in vars() vars() returns a dict of str. So always use a native str for the key lookup. Differential Revision: https://phab.mercurial-scm.org/D7227

automation: install python3-venv Debian package Debian's python install has a crippled venv by default, as it is lacking ensurepip. When you try to run `python3 -m venv` it tells you to install `python3-venv`. So this commit does that in our automation environment so we can fully test installing Mercurial using venv+pip with the system Python. Differential Revision: https://phab.mercurial-scm.org/D7229

tests: look for ensurepip before using venv Debian appears to cripple the venv module by default by removing the associated ensurepip functionality. (The module isn't present at all.) This caused test-install.t to fail when using the Debian python3 unless the python3-venv package was installed. This commit introduces a new hghave requirement for detecting ensurepip and makes the Python 3 install variant conditional on its presence. This should make test-install.t pass when using an incomplete Debian Python. Differential Revision: https://phab.mercurial-scm.org/D7228

automation: avoid '~' in the temp directory on Windows If a long-ish username is used, the environment variable ends up with a '~' to be 8.3 path compatible. That in turn causes a handful of tests (mostly ssh related) to add quotes around $TESTMP. I have no AWS experience, so I have no idea if this is the proper way to do it. But I've hit this problem locally, and redirecting the directory is a workaround. I don't recall if the directory is created on demand by the test harness, but presumably if this is configured before the machine boots, Windows will do it for us. Differential Revision: https://phab.mercurial-scm.org/D7130

tests: use venv on Python 3 This test was failing in some Python 3 environments because `$PYTHON -m virtualenv` was somehow resulting in Python 2 being used. Why, I'm not sure. Python 3 includes virtualenv in the standard library as the `venv` module. This commit changes test-install.t to use `$PYTHON -m venv` on Python 3 and `$PYTHON -m virtualenv` on Python 2 (if available). I chose to make some test output duplicated because we can't have nested conditionals and there is no easy way to express ORing of hghave checks. Differential Revision: https://phab.mercurial-scm.org/D7224

tests: remove HGALLOWPYTHON3 reference This variable was removed from setup.py in c3e10f705a6c. Differential Revision: https://phab.mercurial-scm.org/D7223

run-tests: use byte strings for inserted output We were inserting str on Python 3 which resulted in mixed str/bytes types on the list. This would later blow up when trying to write str to the .err file opened in bytes mode. Differential Revision: https://phab.mercurial-scm.org/D7222

contrib: require Python 3.7 for byteify-strings.py bb509f39d387 made an error, it's actually 3.7 that introduced token.COMMENT. Differential Revision: https://phab.mercurial-scm.org/D7220

hghave: fix bytes/string issue on Python 3

packaging: add support for CentOS 8 The resulting executable has not been tested in detail yet. I ran 'hg version' and 'hg clone', which worked fine (except for extensions acting up due to Python 3). Differential Revision: https://phab.mercurial-scm.org/D7216

packaging: allow choosing python version depending on centos version Differential Revision: https://phab.mercurial-scm.org/D7217

fsmonitor: use stringutil.forcebytestr() instead of str() on an exception Similar to 5fa8ac91190e / D7206, should get test-install.t passing on py3. Differential Revision: https://phab.mercurial-scm.org/D7218

py3: add a __str__ method to Abort This improves the rendering of some exceptions by avoiding raw bytestrings, especially when using --traceback option.

py3: add Python 3 exception output to test-lfs-serve-access.t Similar to a973a75e92bf or 3e9c6cef949b.

automation: install black This should unblock us from running the code formatting test in our automated environment. Differential Revision: https://phab.mercurial-scm.org/D7197

py3: use %d to format an int Avoids a TypeError under py3. Fortunately this is very much an edge case since it requires the user to have deliberately created a local tag of the form 'D\d+' that isn't truthful. Differential Revision: https://phab.mercurial-scm.org/D7215

fsmonitor: normalize exception types to bytes Unavailable.msg should now always be bytes. We also rename Unavailable.__str__ to __bytes__ as it always returns bytes. We make __str__ a simple wrapper that decodes that result to str. There's probably some excessive strutil.forcebytestr() in fsmonitor/__init__.py now. But at least the exceptions around type coercion should now be gone. Differential Revision: https://phab.mercurial-scm.org/D7214

fsmonitor: normalize clock value to bytes We normalize the value returned by watchman because we perform a number of compares with this value in code. So the easiest path forward is to normalize to bytes so we don't have to update many call sites. With this commit, the fsmonitor extension appears to be working with Python 3! Although there are still some failures in edge cases... Differential Revision: https://phab.mercurial-scm.org/D7213

fsmonitor: use next() instead of .next() This is needed for Python 3 compatibility. Differential Revision: https://phab.mercurial-scm.org/D7212

fsmonitor: normalize Watchman paths to bytes Otherwise it will be a str on Python 3 and operations below which operate in the bytes domain will fail. Differential Revision: https://phab.mercurial-scm.org/D7211

fsmonitor: handle unicode keys in tuples In Python 3, keys in the bset tuple are typically str, not bytes. PyBytes_AsString() would return NULL. But we weren't checking the return value and this would lead to a segfault. This commit makes the code type and Python version aware. The Python version specific code is to allow us to utilize a modern API for converting str -> char* without having to allocate an extra PyObject. FWIW I wanted to assume that keys were always str. However, there appear to be some bytes keys in some cases. I haven't debugged this further. Differential Revision: https://phab.mercurial-scm.org/D7210

fsmonitor: make _hashignore compatible with Python 3 The Hasher wants a bytes but we were feeding it a str. Let's use our repr() implementation to return bytes. In addition, the hexdigest() would return a str, which would be compared against a bytes and would always fail. Normalize to bytes so the compare works. Differential Revision: https://phab.mercurial-scm.org/D7209

fsmonitor: normalize hostname to bytes Without this, we get a str/bytes mismatching when using % formatting a few lines below. Differential Revision: https://phab.mercurial-scm.org/D7208

fsmonitor: access repo.root There is no repo._root. It looks like fsmonitor has been busted since this access was introduced in ab1900323b1 in July 2019! Differential Revision: https://phab.mercurial-scm.org/D7207

fsmonitor: coerce watchman exception to bytes Without this, we get errors due to passing str to a function which expects bytes. Differential Revision: https://phab.mercurial-scm.org/D7206

fsmonitor: fix str/bytes mismatch when accessing watchman version There were 2 bugs here. First, keys in the tuple are always str. Second, we needed to normalize the value to bytes to prevent a str/bytes mismatch on Python 3. With this commit, `hg debuginstall` with fsmonitor enabled now works on Python 3. Differential Revision: https://phab.mercurial-scm.org/D7205

fsmonitor: reapply b1f62cd39b5c The recent revendoring of pywatchman undid this changeset. Let's reapply it. This commit was generated by running `hg graft -f b1f62cd39b5c`. It applied cleanly. Differential Revision: https://phab.mercurial-scm.org/D7204

fsmonitor: reapply dd35abc409ee The recent revendoring of pywatchman undid this bug fix. Let's reapply it. Differential Revision: https://phab.mercurial-scm.org/D7203

fsmonitor: remove pywatchman from exclusion rule The recently vendored pywatchman code base is now formatted with black. We can now remove pywatchman from our black exclusion rule. Differential Revision: https://phab.mercurial-scm.org/D7202

fsmonitor: refresh pywatchman with upstream This commit vendors pywatchman commit 259dc66dc9591f9b7ce76d0275bb1065f390c9b1 from upstream without modifications. The previously vendored pywatchman from changeset 16f4b341288d was from Git commit c77452. This commit effectively undoes the following Mercurial changesets: * dd35abc409ee fsmonitor: correct an error message * b1f62cd39b5c fsmonitor: layer on another hack in bser.c for os.stat() compat (issue5811) * c31ce080eb75 py3: convert arguments, cwd and env to native strings when spawning subprocess * 876494fd967d cleanup: delete lots of unused local variables * 57264906a996 watchman: add the possibility to set the exact watchman binary location The newly-vendored code has support for specifying the binary location, so 57264906a996 does not need applied. But we do need to modify our code to specify a proper argument name. 876494fd967d is not important, so it will be ignored. c31ce080eb75 globally changed the code base to always pass str to subprocess. But pywatchman's code is Python 3 clean, so we don't need to do this. This leaves dd35abc409ee and b1f62cd39b5c, which will be re-applied in subsequent commits. Differential Revision: https://phab.mercurial-scm.org/D7201

py3: encode strings before setting rev summary in gnuarch converter

py3: use raw string to query EmailMessage in gnuarch converter

py3: use mail.parsebytes() in gnuarch catlog parser We drop 'catlogparser' attribute now unused.

tests: handle Message-Id line wrapping in test-notify-changegroup.t This fixes this test on Python 3 with a long hostname. See changeset 4128ffba4431 for details.

py3: define and use json.loads polyfill Python 3.5's json.loads() requires a str. Only Python 3.6+ supports passing a bytes or bytearray. This commit implements a json.loads() polyfill on Python 3.5 so that we can use bytes. The added function to detect encodings comes verbatim from Python 3.7.

contrib: require Python 3.6 for byteify-strings.py This script makes use of `token.COMMENT`, which apparently isn't present until Python 3.6. So make the script and its test conditional on Python 3.6.

demandimportpy3: only use lazy extension loader on Python 3.6+ There was an inline comment denoting a bug in the lazy extension loader on Python 3.5 which prevents it from working there. But the code was not conditional on the Python version. The result of this was a myriad of failures on Python 3.5 due to getattr() and friends not working on lazy extension modules. By making extension modules non-lazy on Python 3.5, we reduce the number of test failures from 48 to 22 on that Python version.

ui: flush before prompting for input with readline I was using `hg absorb` with Python 3 and noticed that the prompt was appearing without any output about what would be done. After I answered the prompt, the output was printed to stdout. This appears to be a buffering difference between Python 2 and Python 3. To work around it, this commit adds an explicit flush() before calling the raw input function when readline is used.

histedit: restore hex nodeids to be 12 digits long I accidentally switched from 12 digits to 40 digits while making the code py3-compatible. Thanks to Yuya for noticing. Differential Revision: https://phab.mercurial-scm.org/D7200

tests: fix typo "includfe" Differential Revision: https://phab.mercurial-scm.org/D7180

py3: fix fsmonitor's _watchmantofsencoding exception message encoding Differential Revision: https://phab.mercurial-scm.org/D7190

py3: use native strings as keys into **opts in chistedit Now you should be able to successfully confirm your histedit plan (at least in the case I tried). Even continuing after conflicts and finishing the histedit worked. Differential Revision: https://phab.mercurial-scm.org/D7186

py3: open chistedit file in binary mode using vfs We write bytes to the file, so it should be open in binary mode. Opening it via the vfs takes care of that for us. Now you'll get yet a different traceback if you try to confirm you histedit plan. Differential Revision: https://phab.mercurial-scm.org/D7185

py3: avoid another b''.format() in chistedit Now you'll get a different traceback if you try to confirm you histedit plan. Differential Revision: https://phab.mercurial-scm.org/D7184

py3: render message about conflicts in chistedit code Now you can also reorder commits that (potentially) conflict. Just don't try to confirm the changes yet (because then it crashes). Differential Revision: https://phab.mercurial-scm.org/D7183

py3: handle keypresses in chistedit Now you can navigate and change the action for a commit. You can also reorder commits, as long as that doesn't result in a conflict (then it crashes). Differential Revision: https://phab.mercurial-scm.org/D7182

py3: make chistedit render Now you can see the list of commits, but it crashes when you press a key. Differential Revision: https://phab.mercurial-scm.org/D7181

py3: fix exception display encoding in contrib/simplemerge.py Differential Revision: https://phab.mercurial-scm.org/D7191

py3: fix exception message check in test-linerange.py's testOutOfRange Differential Revision: https://phab.mercurial-scm.org/D7192

py3: fix exception message encoding in scmutil.py's simplekeyvaluefile.read Differential Revision: https://phab.mercurial-scm.org/D7193

py3: fix crecord.py's editpatchwitheditor exception message encoding Differential Revision: https://phab.mercurial-scm.org/D7194

py3: fix exception message encoding in infinitepush Differential Revision: https://phab.mercurial-scm.org/D7195

py3: fix fsmonitor's _handleunavailable exception message encoding Differential Revision: https://phab.mercurial-scm.org/D7196

packaging: update built-in Fedora support to Fedora 31 This is now quite easy ...

packaging: refactor "fedora29" target to a single more generic "fedora" target Fedora moves fast in version numbers, and often with Mercurial packaging being backwards compatible. Also, most people use the system package. There is thus much work and tech debt and little value in providing explicit built-in support for several versions. Thus, only aim for providing built-in support for latest Fedora version, and make it easy to update.

packaging: make dockerrpm fedora target more generic Fedora moves fast in version numbers, and often with Mercurial packaging being backwards compatible. Thus, only aim for providing built-in support for latest Fedora version, and make it easy to update. With this refactoring, 'dockerrpm fedora31' also works. 'dockerrpm fedora' will use the 'fedora:latest' Docker image.

packaging: use "python3" for fedora29 ... and as buildrpm default Change the buidrpm default. The CentOS targets explicitly use "python", and changing the default will only influence Fedora 29. A Python 3 package needs python3 dependencies, so pythonexe (and pythonver) is used for specifying dependencies. Other OS versions will keep using "python" as before ... or potentially change to explicit "python2". Fedora 29 packages can thus also still be built for Python 2 - just not in the docker image that is updated for Python 3.

packaging: use "--python python" for centos7 to avoid explicit "python2" This is a partial backout of 92a51a45d44c. We will need to be able to control whether package dependencies are python2 or python3. Generally (at least in recent Fedora), the package prefix match the name of the python executable ... but CentOS 7 doesn't use the python2 prefix in package name or alias for python-docutils yet, so just keep centos7 in the unversioned "python" world. Change the new (unused) buildrpm "--python3" option (introduced in a6dcac6454c1) to "--python python3" to get a more generic method for explicit control over whether we use python, python2 or python3.

packaging: fix docker-centos5 - use pythonexe and set to "python" as before Fix 92a51a45d44c .

packaging: move dockerrpm output directory creation to dockerrpm Avoid having to compute the directory in two places in different environments.

packaging: drop "support" for unsupported Fedora versions Fedora 31 has just been released, and Fedora 29 will be EOL in a month. Don't spend any time thinking about dead stuff.

mail: black wants to add this blank line I can't figure out how this got overlooked on previous runs, but here we are. It looks like the culprit change is already public?

hghave: verify we have a black that is new enough for our format We require what is currently the absolute latest black, so let's be paranoid.

contrib: fix up example fix configuration for our move to released black

phabricator: use True primitive instead of b'true' for phabupdate actions Something I'd missed in the creatediff port. This didn't matter before with the old PHP form style wireformat, but breaks with the new arcanist format. Differential Revision: https://phab.mercurial-scm.org/D7152

setup: allow py3 install without env vars 5.2 is the first release of Mercurial where py3 support is expected to be widely used, therefore we should allow installing it without hoop-jumping. Differential Revision: https://phab.mercurial-scm.org/D7151

formatting: drop `grey`, our custom black version Now that the official black has all we want, we can drop this.

formatting: using black to check for formatting

formatting: run black version 19.10b0 on the codebase The latest version of black is out and contains the change we needed. So we can start using it now. note: `test-check-format.t` will complains about this changes because it still use `grey` and need to be migrated to `black`. See next changesets for this.

packaging: fix buildrpm whitespace

packaging: drop outdated buildrpm "tested on" comment Packaging usually works on other versions too, and it is not efficient to maintain the list in repo. It is already out of sync with the Makefile targets.

packaging: also include hgweb.wsgi in rpms

packaging: introduce Python3 support as buildrpm --python3 Just overrule the HGPYTHON3 warning.

packaging: be explicit about Python version in rpm spec Fedora 31 has Python3 at /usr/bin/python ... but expect everybody to not just find python in $PATH but be explicit about whether they want python2 or python3. mercurial.spec just used 'python' and would fail when it unknowingly used Python 3 and ended up with Mercurial setup.py reporting "Python 3.7 detected." and talking about the HGPYTHON3 environment variable. For now, just be explicit about using system python2 as python executable when building rpms.

packaging: make python snippets in rpm building python3 compatible Fedora 31 has Python3 at /usr/bin/python, and buildrpm would fail on snippets that use python2 syntax. Instead of forcing python2, just accept for the future while staying backwards compatible.

py3: fix patchbomb to accept non-ASCII header value for email preview Since mail.headencode() is disabled by -n/--test, non-ASCII header value has to be allowed. Spotted by Denis Laxalde.

tests: check patchbomb with a non-ascii commit message This fails on Python 3 but gets fixed in the next changeset.

formatter: fix handling of None value in templater mapping For historical reasons, None in mapping dict means there's no such keyword, and falls back to b"". That's fine in log templates where mapping item is generally a callable returning a value (which may be None,) but the formatter directly puts an "evaluated" value in the mapping. So the None value has to be lifted to wrappedvalue(None) to avoid confusion in the template engine.

config: add support for defaultvalue of list of printable elements

config: fix -Tjson to not crash due to unsupported defaultvalue types Maybe it isn't great to ignore unsupported types at all, but otherwise "hg config -Tjson" would crash.

tests: handle Message-Id email header possible wrapping The "Message-Id" header will get wrapped with a new line when exceeding 75 characters on Python 3 (see changeset 7d4f2e4899c5 introducing usage of email.header.Header.encode and respective doc). This will occur in an unpredictable manner depending on the hostname's length. To make the test output consistent across Python versions and hostname configuration, we add a filter to unwrap this header value.

py3: leverage pycompat.long

packaging: remove version info from Breaks+Replaces in Debian package The versioned Breaks: and Replaces: cause problem when trying to install our package over the one in Debian. $ sudo apt install ./packages/debian-buster/mercurial_5.2~rc0+15-buster-a2ff3aff81d2_amd64.deb Reading package lists... Done Building dependency tree Reading state information... Done Note, selecting 'mercurial' instead of './packages/debian-buster/mercurial_5.2~rc0+15-buster-a2ff3aff81d2_amd64.deb' Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: mercurial : Breaks: mercurial-common (< 5.2~rc0+15-buster-a2ff3aff81d2) but 5.2~rc0-1 is to be installed E: Unable to correct problems, you have held broken packages. Removing version information resolves the situation.

py3: fix generated non-ascii message in test-notify.t The resulting "Subject:" header contains an encoded word in Python 3 so we have to add distinct outputs for Python 3 but underlying values are the same: >>> from email.header import decode_header >>> decode_header('=?utf-8?b?w6AuLi4=?=') [(b'\xc3\xa0...', 'utf-8')]