wait-on-file: use proper variable in math This seems better and safer to be explicit. Differential Revision: https://phab.mercurial-scm.org/D8426

wait-on-file: don't quote arithmetic argument This is unnecessary and Mac OS X choke on them. Differential Revision: https://phab.mercurial-scm.org/D8425

graft: exit 1 on conflicts, like merge It's more consistent, and makes it nicer to script around hg if you don't have to ignore exit code 255, which is the error code for basically everything in hg. Differential Revision: https://phab.mercurial-scm.org/D8423

tests: deal with "ls" vs "ls -A" difference on 2BSD derived systems BSD-derived systems will use "ls -A" when running as root. Adjust the test cases to always use the flag and include .hg and related output as appropiately. Differential Revision: https://phab.mercurial-scm.org/D8397

tests: skip non-readable check for root Trying to check for errors on non-readable hgrc requires UNIX permissions, but still won't work for root. So adjust the check. Differential Revision: https://phab.mercurial-scm.org/D8396

tests: skip CVS tests for root It is not uncommon for cvs to check for root and to refuse work in that case. Differential Revision: https://phab.mercurial-scm.org/D8395

make: drop the `-c` arg to `install` in the documentation makefile This arg caused `gmake install` on OpenIndiana 2019.10 (illumos) fail with: install: The -c, -f, -n options each require a directory following! install: The -c, -f, -n options each require a directory following! install: The -c, -f, -n options each require a directory following! gmake[1]: *** [Makefile:41: install] Error 2 gmake[1]: Leaving directory '/usr/local/share/mercurial/doc' The workaround is to run `gmake install-bin`. The man page for 10.14 says this is to copy the file and is only for compatability, as it is the default. The CentOS 7 man page says it is ignored. The top level makefile doesn't use this argument at all, so I'm not sure why it's here. Differential Revision: https://phab.mercurial-scm.org/D8439

phabricator: restack any new orphans created by phabsend (issue6045) Previously, posting a new review for a non head commit would orphan the head. The general case is any descendant of the selected revisions got orphaned if this was the first time the selected revisions were submitted. It doesn't happen when resubmitting. I've already had coworkers hit this a few times and get confused. Since posting a review isn't generally thought of as an editing operation, it would probably be easier for new users if we just restacked. This avoids restacking existing orphans around the submission because that may involve merge conflict resolution. Users who already have orphans should know how to stabilize them anyway. Differential Revision: https://phab.mercurial-scm.org/D8438

phabricator: prevent posting obsolete commits I don't see why this would be useful in the first place. But I had a coworker submit a single commit that was not a branch head, and the result was to orphan its child and keep the original commit visible. He then did up arrow + Enter, and it happily created a new review (since the URL isn't amended into the original commit specified on the command line) and a new successor, resulting in a local divergence. I'd like to fix the issue with creating orphans, but this is simple enough to prevent on its own. Differential Revision: https://phab.mercurial-scm.org/D8437

phabricator: avoid creating unstable children within the review stack The instability occurred when rebasing something that has already been submitted onto something that hasn't, and then resubmitting the stack. Or as the test shows, just resubmitting and including something earlier that wasn't previously submitted. There's a general case here where any children (not just the ones in the range of commits posted for review) should be re-stabilized. But handling the selected commits here will cause the `local:commit` node values that are tracked on Phabricator to be properly kept in sync. Differential Revision: https://phab.mercurial-scm.org/D8436

phabricator: add an option to fold several commits into one review (issue6244) Now that all of the pieces are in place, alter the user facing command to allow it. This is the default behavior when using `arc`, but I much prefer the 1:1 approach, and I'm tempted to mark this advanced to limit its abuse. I started out calling this `--no-stack` like the feature request suggested, but I found it less obvious (especially when writing the code), so I went with the `hg fold` analogue. This will populate the `Commits` tab in the web UI with the hash of each commit folded into the review. From experimentation, it seems to list them in the order they are received from the extension instead of the actual parent/child relationship. The extension sends them in sorted order, thanks to `templatefilters.json()`. Since there's enough info there for them to put things in the right order, JSON is unordered aside from lists (IIUC), and there doesn't seem to be any harmful side effects, I guess we write this off as their bug. It is simple enough to workaround by putting a check for `util.sortdict` into `templatefilters.json()`, and don't resort in that case. There are a handful of restrictions that are documented in the code, which somebody could probably fix if they're interested. Notably, this requires the (default) `--amend` option, because there's not an easy way to apply a local tag across several commits. This also doesn't do preflight checking to ensure that all previous commits that were part of a single review are selected when updating. That seems expensive. What happens is the excluded commit is dropped from the review, but it keeps the Differential Revision line in the commit message. Not everything can be edited, so it doesn't seem worth making the code even more complicated to handle this edge case. There are a couple of "obsolete feature not enabled but X markers found!" messages that appeared on Windows but not macOS. I have no idea what's going on here, but that's an unrelated issue, so I conditionalized those lines. Differential Revision: https://phab.mercurial-scm.org/D8314

tests: move the phabricator auth token to the global config file The next commit introduces a new repo to simplify its development. This value needs to be modified to record tests, so it doesn't make sense to have to do that twice. The callsign and URL are *not* moved because there are tests that fallback to the .arcconfig file when those aren't present. Differential Revision: https://phab.mercurial-scm.org/D8390

phabricator: add debug logging to show previous node values in `phabsend` This isn't real useful here, but was very useful showing how `phabsend --fold` handles commits created by `hg fold` and `hg split`. It introduces a new debug function and flag instead of using `ui.debug()`, because `--debug` prints out all of the API chatter. Differential Revision: https://phab.mercurial-scm.org/D8389

rust: update README with new information about the Re2 path Differential Revision: https://phab.mercurial-scm.org/D8452

rust: add option of static linking a local Re2 install Previously, only dynamically linking the system-wide install was possible. We force the user to provide one to prevent hard-to-track errors. Differential Revision: https://phab.mercurial-scm.org/D8451

templatekw: cache mergestate even if merge is not ongoing While playing with eBPF, I noticed .hg/merge/state{,2} files were tried to open() for each revision. That's not healthy. Let's cache the "inactive" state as well.

revset: remove explicit sort() from unstable() The instability should be dealt with by baseset.__init__(), and the returned smartset is ordered by 'subset &' anyway.

revset: implement a simple 'foo#generations' expression The result of this expression is equivalent to 'foo#g[:]': all reachable ancestors and descendants of a revset foo. While not very useful functionality on its own, its implementation can be tested and revset.relations dict can be easily used by extensions to add other non-subscript relations. Differential Revision: https://phab.mercurial-scm.org/D8394

revset: rename generationsrel() to generationssubrel() This highlights that this is an implementation of 'x#y[z]' relation subscript operator as opposed to 'x#y' relation operator. Differential Revision: https://phab.mercurial-scm.org/D8393

manifest: leave a TODO where we may have more work for sha1 portability Differential Revision: https://phab.mercurial-scm.org/D8375

manifest: add test for long hashes Differential Revision: https://phab.mercurial-scm.org/D8373

manifest: remove a final 40-byte assumption from pure-python parser Differential Revision: https://phab.mercurial-scm.org/D8372

manifest: fix yet another 20-byte-hash assumption Differential Revision: https://phab.mercurial-scm.org/D8371

manifest: fix another pure-parsing 20-byte assumption Differential Revision: https://phab.mercurial-scm.org/D8370

manifest: teach treemanifest about long hashes Differential Revision: https://phab.mercurial-scm.org/D8369

manifest: start removing 40-byte hash restrictions from C code Differential Revision: https://phab.mercurial-scm.org/D8368

manifest: remove a 20-byte-hash assumption from pure manifest parsing This is almost certainly slower, but it shouldn't be by much. We need to do this for the eventual hash transition, no matter what that looks like. Differential Revision: https://phab.mercurial-scm.org/D8367

revset: mark `extinct()` experimental Differential Revision: https://phab.mercurial-scm.org/D8407

revset: mark `successors()` experimental Differential Revision: https://phab.mercurial-scm.org/D8406

revset: mark `obsolete()` experimental I assume not marking it was unintentional, since the obsolete concept it still experimental. Differential Revision: https://phab.mercurial-scm.org/D8405

nodemap: access the mmap opener option using bytes The key is bytes and need to be accessed s such. Differential Revision: https://phab.mercurial-scm.org/D8413

nodemap: rename a variable to prevent shawoding "_" This will make pyflakes happy with the next changeset. Differential Revision: https://phab.mercurial-scm.org/D8412

rust-chg: indent process_message() to prepare mass rewrite to futures-0.3 I'll start upgrading the codebase to modern async/await-based implementation, which cannot be done incrementally. This is the last non-breaking patch to prepare for the rewrite. Differential Revision: https://phab.mercurial-scm.org/D8403

rust-chg: move get_umask() call out of run() function run() will be an async function, but get_umask() isn't thread safe. Differential Revision: https://phab.mercurial-scm.org/D8402

rust-chg: leverage impl trait at argument position Differential Revision: https://phab.mercurial-scm.org/D8401

setup: link osutil.so to libsocket on Solaris/illumos (issue6299)

revset: import `unstable()` from the evolve extension Differential Revision: https://phab.mercurial-scm.org/D8404

fastexport: make a diagnostics message more localizable Differential Revision: https://phab.mercurial-scm.org/D8398

rust-chg: use "crate::" to import local modules I feel it's easier to follow to resolve modules from the crate root than relative path from self module. Differential Revision: https://phab.mercurial-scm.org/D8400

rust-chg: upgrade to 2018 edition and remove useless extern crates Differential Revision: https://phab.mercurial-scm.org/D8399

mergestate: store about files resolved in favour of other Committing a merge sometimes wrongly creates a new filenode where it can re-use an existing one. This happens because the commit code does it's own calculation and does not know what happened on merge. This starts storing information in mergestate about files which were automatically merged and the other/remote version of file was used. We need this information at commit to pick the filenode parent for the new commit. This issue was found by Pierre-Yves David and idea to store the relevant parts in mergestate is also suggested by him. Somethings which can be further investigated are: 1) refactoring of commit logic more to depend on this information 2) maybe a more generic solution? Differential Revision: https://phab.mercurial-scm.org/D8392

histedit: add test that an invalid editor doesn't bork client state We had a report of a situation like this borking a user at Google, but I can't reproduce it in a test. Let's at least backstop the issue with a test, so we don't accidentally introduce such a bug... Differential Revision: https://phab.mercurial-scm.org/D8391

rust-chg: silence warning about dated coding style Differential Revision: https://phab.mercurial-scm.org/D8384

rust-chg: update name of the server process This is a copy of updateprocname() of hgclient.c. At this point, rust-chg is basically functional. I did dogfooding for a couple of weeks in 2018. There are a few remaining tasks: a. loop detection by CHGINTERNALMARK b. forward unsupported commands (notably serve -d) to real hg c. better handling of early server exception d. modernize codebase (2018 edition, impl trait, async/await) For (d), we'll probably want to switch to async-std, but I'm thinking of upgrading to Tokio 0.2 as an intermediate step since process API isn't ported to async-std yet. I'm pretty sure future migration to async-std will be painless compared to the mass rewrite from futures-0.1 to 0.3. https://github.com/async-rs/async-std/issues/22 Differential Revision: https://phab.mercurial-scm.org/D8383

rust-chg: send client side umask to server This is equivalent to forwardumask() of hgclient.c. Differential Revision: https://phab.mercurial-scm.org/D8382

rust-chg: add config validation and process returned instructions This is the reimplementation of runinstructions() and main() in chg.c. In Rust version, we only pass in early arguments to the server as the locator doesn't know the full arguments. This should be fine since these arguments are just passed in to _earlyparseopts() and _parseconfig(), which means the server doesn't need full arguments. Another difference is the handling of the "exit <code>" instruction. In Rust version, we can simply reuse the connection instead of "exit(code)" as the command error isn't displayed yet. That's because the client-side stdio is not attached until the connection is validated. This behavior is cleaner than C, but it also means that the early server exception wouldn't be propagated to client because stderr isn't attached. So we might have to reconsider when to attach/detach the server stdio. Differential Revision: https://phab.mercurial-scm.org/D8381

rust-chg: collect server flags from command arguments This is the reimplementation of testsensitiveflag() and setcmdserverargs() of chg.c. Differential Revision: https://phab.mercurial-scm.org/D8380

rust-chg: add interface to run "validate" request Differential Revision: https://phab.mercurial-scm.org/D8379

rust-chg: add helper to parse instructions sent from server This is well structured version of runinstructions() of chg.c. Differential Revision: https://phab.mercurial-scm.org/D8378

tests: move verification closer to setup in test-copies-chain-merge.t I found this test case really hard to read because it requires scrolling back and forth between the setup and the verification. This patch moves them closer together. There was also duplicated descriptions for each test case (duplicated between setup and verification). They had already become out of sync. I picked the description from the verification, partly so the differences would be highlighted in this patch. Differential Revision: https://phab.mercurial-scm.org/D8377

tests: collect all branch creation in one place in test-copies-chain-merge.t I found this test case really hard to read because it requires scrolling back and forth between the setup and the verification. The next patch will move the verification close to the merge commits they test. This patch prepares for that by moving all branch creation first so they are separate from the merge commits (because many merge commits reuse the same branches). Differential Revision: https://phab.mercurial-scm.org/D8376

hgk: remove a "b" used on a kwargs expansion, the keys are strs Differential Revision: https://phab.mercurial-scm.org/D8385

rust-chg: send client-side environment variables to server This is also needed to run config validation. The "validate" request and its response handling will be implemented in the next batch. Differential Revision: https://phab.mercurial-scm.org/D8364

rust-chg: add helper to pack environment variables On my machine, "printenv | wc -c" says 3422. That's the only reason why the initial buffer capacity is set to 4kB. Differential Revision: https://phab.mercurial-scm.org/D8363

rust-chg: move set_current_dir() to Locator This is necessary to run config validation in proper environment. Differential Revision: https://phab.mercurial-scm.org/D8362

rust-chg: abort if server doesn't have required capabilities It's checked at Locator::connect() since we'll have to do more stuff in this function. Differential Revision: https://phab.mercurial-scm.org/D8361

rust-chg: spawn server process if not running This is the minimal reimplementation of gethgcmd(), execcmdserver(), retryconnectcmdserver(), and connectcmdserver() in chg.c. No config validation is implemented yet. And some Py3 workarounds would be missing as this is the code I wrote in 2018. Differential Revision: https://phab.mercurial-scm.org/D8360

rust-chg: update dependencies Differential Revision: https://phab.mercurial-scm.org/D8359

rust-chg: depend on released version of tokio-process Still it is futures-0.1 based. Differential Revision: https://phab.mercurial-scm.org/D8358

rust-chg: add brief comment about initial capacity of temp_sock_path() I don't know if it can be expressed as a compile-time constant, so it's a comment for now. About this series: This is quite old patches for rust-chg. I heard from Octobus people that there's a plan to do an experiment on merging hgcli + chg + some Rust?, so I decided to respin the rust-chg series. Maybe we'll rewrite the core to leverage the recent async/await functionality, but I want to first make my old patches in so the rust-chg can be a drop-in replacement for the chg of C. Compiler warnings will be removed later, and the codebase will be upgraded to the 2018 edition later. Differential Revision: https://phab.mercurial-scm.org/D8357

discovery: avoid wrongly saying there are nothing to pull We can get in a situation where a revision passed through `hg pull --rev REV` are available on the server, but not a descendant of the advertised server heads. For example the server could lying be during heads advertisement, to hide some pull request. Or obsolete/hidden content could be explicitly pulled. So in this case the lookup associated to `REV` returned successfully, but the normal discovery will find all advertised heads already known locally. This flip a special boolean `anyinc` that will prevent any fetch attempt, preventing `REV` to be pulled over. We add three line of code to detect this case and make sure a pull actually happens. My main target is to make some third party extensions happy (I expect the associated test to move upstream with the extension). However this fix already make some of the `infinitepush` test happier.

rebase: don't create merge when continuing rebase interrupted by old hg This fixes the bug described and demonstrated in the previous commit. It does so by practically undoing 8082a77cc3a2 (rebase: remove some redundant setting of dirstate parents, 2020-01-10). Differential Revision: https://phab.mercurial-scm.org/D8356

tests: demonstrate how continuing rebase after upgrade can result in merge If the user starts a rebase with an hg version before 9c9cfecd4600 (rebase: don't use rebased node as dirstate p2 (BC), 2020-01-10) and then runs into conflicts, they will be dropped out to the shell with the rebased node set as the dirstate's second parent. If they then upgrade to a later hg version, it will respect the dirstate's parents and will create a merge commit even if the user was rebasing a non-merge commit. Differential Revision: https://phab.mercurial-scm.org/D8355

manifest: also declare treemanifest as implementing imanifestdict It always has been intended to be, but it had a mismatched flags() method until the previous change. Differential Revision: https://phab.mercurial-scm.org/D8366

manifest: introduce new exception to signal unavailability of fastdelta() I've spent some time reflecting on this, and I think this is the best we can do in this API contract for now. This opens the door to adding treemanifest's implementation to the list of implementers of imanifestdict. Differential Revision: https://phab.mercurial-scm.org/D8365

copies-tests: remove spurious `]` in the template Fixing this typo happily impact all the tests output. Differential Revision: https://phab.mercurial-scm.org/D8258

merge with stable

debugcommands: fix typo in debuguigetpass

dagop: fix subsetparentswalker to set p1/p2 chains at merge revision The previous implementation was wrong because the '1'/'2' key would be appended at a fork revision. Since we traverse the graph from heads, a merge revision is actually a branching point, where the sort key must be generated.

dagop: simplify dict/set reuse condition in subsetparentswalker Prepares for fixing the calculation of p1/p2 sort keys. With this change, there will be one more copying on merge&fork case. I think the copying cost is negligible since we'll have to update each item in the dict on merge/fork.

extensions: refactor function for obtaining disabled extension help The way this worked before was hgext.__index__ was consulted. This file appears to only be present on some Windows distributions. This file contains a dict mapping extension name to its summary line, not its full docstring. The problem with this is that code in the help system was calling this function to resolve help text. If hgext.__index__ was present, only the summary line would be displayed. If not, the full extension help would be printed. This commit changes the function to not use hgext.__index__ such that it always returns the full extension help text. As a result of this change, test-extension.t and test-qrecord.t now pass when run from environments that have an hgext.__index__. Differential Revision: https://phab.mercurial-scm.org/D8344

tests: perform grep manually in test-doctest.py This test has been failing on Windows since 0af56d3ee24c introduced the `hg files` invocation. Specifically, Windows seems to be choking on special characters in the fileset pattern. I believe at least \n and > were causing issues. I attempted various incantations to make the Windows command line parser accept the fileset but couldn't get anything working. I declared bankruptcy and just reimplemented the grepping code in Python. After this change, the test now passes on Windows again. Differential Revision: https://phab.mercurial-scm.org/D8343

tests: prevent printing \r to stdout Like we've done in other recent commits, we need to change sys.stdout on Python 3 to not use os.linesep so output is consistent on Python 3 on Windows. With this change, test-notify.t now passes on Python 3 on Windows! Differential Revision: https://phab.mercurial-scm.org/D8342

tests: force \n newlines when writing to sys.stdout Without this, Python 3 on Windows inserts some \r that aren't present in the input, causing test-http-bad-server.t to fail. After this change, the test passes on Python 3 on Windows! Differential Revision: https://phab.mercurial-scm.org/D8341

dispatch: force \n for newlines on sys.std* streams (BC) The sys.std* streams behave differently on Python 3. On Python 3, these streams are an io.TextIOWrapper that wraps a binary buffer stored on a .buffer attribute. These TextIOWrapper instances normalize \n to os.linesep by default. On Windows, this means that \n is normalized to \r\n. So functions like print() which have an implicit end='\n' will actually emit \r\n for line endings. While most parts of Mercurial go through the ui.write() layer to print output, some code - notably in extensions and hooks - can use print(). If this code was using print() or otherwise writing to sys.std* on Windows, Mercurial would emit \r\n. In reality, pretty much everything on Windows reacts to \n just fine. Mercurial itself doesn't emit \r\n when going through the ui layer. Changing the sys.std* streams to not normalize line endings sounds like a scary change. But I think it is safe. It also makes Mercurial on Python 3 behave similarly to Python 2, which did not perform \r\n normalization in print() by default. .. bc:: sys.{stdout, stderr, stdin} now use \n line endings on Python 3 Differential Revision: https://phab.mercurial-scm.org/D8339

hook: move stdio redirection to context manager The old code was checking stdio redirection in a loop. This didn't make sense. The pattern is better expressed as a context manager IMO, so this commit refactors it to be one. Differential Revision: https://phab.mercurial-scm.org/D8338

pycompat: change argv conversion semantics Use of os.fsencode() to convert Python's sys.argv back to bytes was not correct because it isn't the logically inverse operation from what CPython was doing under the hood. This commit changes the logic for doing the str -> bytes conversion. This required a separate implementation for POSIX and Windows. The Windows behavior is arguably not ideal. The previous behavior on Windows was leading to failing tests, such as test-http-branchmap.t, which defines a utf-8 branch name via a command argument. Previously, Mercurial's argument parser looked to be receiving wchar_t bytes in some cases. After this commit, behavior on Windows is compatible with Python 2, where CPython did not implement `int wmain()` and Windows was performing a Unicode to ANSI conversion on the wchar_t native command line. Arguably better behavior on Windows would be for Mercurial to preserve the original Unicode sequence coming from Python and to wrap this in a bytes-like type so we can round trip safely. But, this would be new, backwards incompatible behavior. My goal for this commit was to converge Mercurial behavior on Python 3 on Windows to fix busted tests. And I believe I was successful, as this commit fixes 9 tests on my Windows machine and 14 tests in the AWS CI environment! Differential Revision: https://phab.mercurial-scm.org/D8337

Added signature for changeset 8fca7e8449a8

Added tag 5.3.2 for changeset 8fca7e8449a8

phabricator: extract logic to print the status when posting a commit This will make it easier to list each commit when folding. That makes the output less confusing because it matches the output of `--confirm` and the revisions listed on the command line. Differential Revision: https://phab.mercurial-scm.org/D8313

phabricator: extract the logic to amend diff properties to a function This will be needed on a separate code path when dealing with folding revisions. And since we know that will involve adding multiple local commmits to the diff properties instead of just one, restructure the logic slightly to allow it. Differential Revision: https://phab.mercurial-scm.org/D8312

phabricator: teach `getoldnodedrevmap()` to handle folded reviews The tricky part here is reasoning through all of the possible predecessor scenarios. In the typical case of submitting a folded range and then resubmitting it (also folded), filtering the list of commits for the diff stored on Phabricator through the local predecessor list for each single node will result in the typical 1:1 mapping to the old node. There are edge cases like using `hg fold` within the range prior to resubmitting, that will result in mapping to multiple old nodes. In that case, the first direct predecessor is needed for the base of the diff, and the last direct predecessor is needed for the head of the diff in order to make sure that the entire range is included in the diff content. And none of this matters for commits in the middle of the range, as they are never used. Fortunately the only crucial thing here is the `drev` number for each node. For these complicated cases where there are multiple old nodes, simply ignore them all. This will cause `createdifferentialrevision()` to generate a new diff (within the same Differential), and avoids complicating the code. Differential Revision: https://phab.mercurial-scm.org/D8311

phabricator: teach createdifferentialrevision() to allow a folded commit range No visible changes here, until an option to enable it is added to `phabsend`. Differential Revision: https://phab.mercurial-scm.org/D8310

phabricator: combine commit messages into the review when folding commits No visible changes here, until an option to enable it is added to `phabsend`. This combines the Differential fields like Arcanist does, rather than simply concatenating the text blocks. Aside from populating everything properly in the web interface, Phabricator fails the review create/update if repeated fields are seen as would happen with simple concatenation. On the flip side, now that the Summary and Test Plan fields can contain data from multiple commits, we can't just join these fields together to determine if an amend is needed. If that were to happen, every single commit in the folded range would get amended with the combined commit message, which seems clearly wrong. Aside from making a minor assumption about the content of the Differential Revision field (it seems they allow some minor variances with spacing), this means that for folded reviews, you can't post it, go to the web page add a missing Test Plan, and then get it added to the commit message by re-posting it. I don't think that's a big deal. Differential Revision: https://phab.mercurial-scm.org/D8309

phabricator: record all local commits used to create a Differential revision Arcanist records all of the commits that it squashes into a single review, and that info will be helpful when adding similar functionality. This info is used when submitting an updated review, so that the extension can recalculate the old diff and see if a new one is necessary, or if it is just a property update. It also shows on the `commits` tab in the `Revision Contents` section. When submitting in the usual 1:1 commit to review mode, the wire protocol is unchanged. The content of `hg:meta` is a bit odd, but such is the problem when folding several commits. The choice for the parent node is obvious, but the `node` value uses the tip commit because that seems more natural, and is used elsewhere to look up the previous diff when updating. The rest of the attributes follow from there. Differential Revision: https://phab.mercurial-scm.org/D8308

tests: use `f --hexdump` to print file content The inline print.py in this test wasn't fully compatible with Python 3 because it was reading from sys.stdin, which already normalized line endings since it operates in the realm of str on Python 3. To do this correctly, we'd need to read from sys.stdin.buffer on Python 3. This would entail conditional code. I felt this was too much effort. So I just replaced the custom script with `f`, which already knows how to do the right thing. test-mactext.t now passes on Python 3 on Windows. Differential Revision: https://phab.mercurial-scm.org/D8336

url: pass str to pathname2url This is needed to appease Python 3. This fixes test-extdata.t and test-url-download.t on Python 3 on Windows. Differential Revision: https://phab.mercurial-scm.org/D8335

tests: pass str to matchoutput() It accepts a str, not bytes. This fixes a failure in test-hghave.t on Windows. Why it wasn't failing on Linux, I don't know. I suspect the Windows process code in Python doesn't accept bytes and the POSIX code does? Differential Revision: https://phab.mercurial-scm.org/D8334

hgcli: customize for Mercurial Now that we have a shiny new PyOxidizer-based hgcli project, let's customize it for Mercurial! This commit replaces the auto-generated pyoxidizer.bzl with one that installs Mercurial from the local source repository. A README.md with build instructions has been added. The Cargo.toml file has been updated to reflect the proper license and reference the added README.md. In my Linux environment, running the test suite yields 27 failures. It's worth noting the run time of the test harness on Linux on my Ryzen 3950X: before: 378s wall; 9982s user; 1195s sys after: 353s wall; 8996s user; 958s sys % orig: 93.4 wall; 90.1 user; 80.2 sys While I haven't measured explicitly, I suspect the performance win is due to in-memory resource loading (which is known to be faster than Python's filesystem importer). Differential Revision: https://phab.mercurial-scm.org/D8351

hgcli: add stub PyOxidizer project Using commit c772a1379c3026314eda1c8ea244b86c0658951d of PyOxidizer, I ran `pyoxidizer init-rust-project hgcli` to create a stub Rust project. The only modifications I made from what that command produced are: * Update location of pyembed crate to PyOxidizer's Git repository. * Removed some trailing whitespace from pyoxidizer.bzl * Added auto-generated Cargo.lock file Subsequent commits will modify the stub project to Mercurial's needs. Differential Revision: https://phab.mercurial-scm.org/D8350

hgcli: remove legacy project This code is a logical precursor to PyOxidizer. It is now defunct. Differential Revision: https://phab.mercurial-scm.org/D8349

nodemap: automatically "vacuum" the persistent nodemap when too sparse We arbitrarily pick "10%" as the threshold. Differential Revision: https://phab.mercurial-scm.org/D8193

nodemap: display percentage of unused in `hg debugnodemap` This is useful to assess the density of the cache. Differential Revision: https://phab.mercurial-scm.org/D8192

nodemap: make sure on disk change get rolled back with the transaction In case of errors, we need to rollback the change made to the persistent nodemap. Differential Revision: https://phab.mercurial-scm.org/D8191

nodemap: test that concurrent process don't see the pending transaction We don't want other client to read uncommitted data, until the transaction is really committed. Differential Revision: https://phab.mercurial-scm.org/D8190

testlib: adjust wait-on-file timeout according to the global test timeout Lets assume that if test timeout have been set to be twice as long, it means local timeout should be twice as long too. I am not aware of any case were extending timeout for file based synchronisation was necessary, but the safety seems simple to implements. Differential Revision: https://phab.mercurial-scm.org/D8316

testlib: add a small scrip to help process to synchronise using file Creating and waiting for files is a robust way to synchronise two processes running concurrently. We already use this approach in various tests. I am adding a official script to do so before adding more usage of this. Differential Revision: https://phab.mercurial-scm.org/D8189

setup: work around old versions of distutils breaking setup.py I'm not really sure how to trigger this, but we saw it in our build environment for Windows at Google. This fixed it. Sigh.

chgserver: update the umask cache before each run posix.py uses a global variable to store the umask value resulting in caching of it when using chg. We need to update it before each command run as the umask can change between commands. This fixes test-inherit-mode.t with chg.

tests: handle new error string from FreeBSD for dns entry not resolving Differential Revision: https://phab.mercurial-scm.org/D8333

notify: optional mail threading based on obsmarker When notify.reply is set and a changeset has a predecessor in the repository, include In-Reply-To pointing to the message-id that would have been generated for the oldest predecessor. This allows mail threading like Phabricator for common cases like rebasing changes, but will be optimal for cases like folding. Differential Revision: https://phab.mercurial-scm.org/D8172

pathutil: document that dirs map type implies manifest/dirstate processing

git: pass a list to pathutil.dirs to indicate that it is a manifest The python implementation of pathutil.dirs just uses a for loop which happens to work the same on both dicts and lists. The rust implementation actually figures out which of the two types it is, and directs the execution to either dirstate or manifest processing.

git: implement basic bookmark activation This is very limited, but it allows 'hg update foo' when already on foo. The caching is based on bmstore's caching.

git: implement a basic checkconflict bookmark store method It is heavily based on bmstore's own checkconflict.

git: abort when attempting to set a branch Given the mapping we use (namely, a git head is a bookmark), it is better to error out with a hint.

git: remove obsolete todo item The changes in 02c47b74366c cleaned up the requirement check.

tests: don't run test-update-atomic.t on chg I am unable to find a good way to make `showwrites` extension in it to work with chg. Also putting the use of showwrites inside `if no-chg` will defeat the purpose of test, so I just made the test no-op on chg.

tests: don't run couple of tests related to extensions loading with chg The couple of files test extensions loading and debugging that. It sets `devel.debug.extensions` to True to do that. Either we have to restart chg if this config is set or just don't run these tests on chg. I tried the first way by adding the config option to chgserver.py list of config subsections but that does not seem to work.

tests: conditionalize test-phases.t output for chg IIUC chg loads the ProgrammingError class which leads to it directly referencing it in error output. This makes the test pass on chg.

chg: be stricter about checking invocation of `serve` command Few tests run serve command in form of `hg -R <repo> serve` which leads to chg thinking that it's not a serve command and failing tests. We become more stricter in checking for the serve command. This fixes test-server-view.t, test-remote-hidden.t, test-remotefilelog-http.t, test-phases-exchange.t, test-wireproto-content-redirects.t with chg.

chgserver: add merge-tools to sensitive config items Because this can change whether the ui is gui or not. This fixes test-extdiff.t with chg.

run-tests: add --chg-debug flag to show chg debug output This has helped me a lot in debugging chg failures in tests.

tests: update test-ssh.t output with --chg The output change was caused by d7304434390f5efca405744fa12a6585edae3d83.

tests: update test-devel-warnings.t output with chg The output change was caused by dc9901558e3c6a78bad3f6594b3888f95104c443.

chgserver: add fastannotate config section to sensitive list Depending on the config value of `fastannotate.modes`, the fastannotate extension can do different things in uisetup. Depending on value of `fastannotate.server`, it can register new wireprotocol capabilities. This fixes test-fastannotate-hg.t, test-fastannotate-protocol.t and test-fastannotate.t with chg.

histedit: add missing b prefix to a string If i18n is disabled (such as via HGPLAIN=1), `_()` doesn't convert from str to bytes, so this raises a TypeError on py3. Differential Revision: https://phab.mercurial-scm.org/D8354

phabricator: account for `basectx != ctx` when calculating renames No functional changes here because the two are the currently same, but they won't be with a `--fold` option. Differential Revision: https://phab.mercurial-scm.org/D8307

phabricator: add basectx arguments to file related `phabsend` utilities This is in support of a future `--fold` option, that allows rolling up several commits into a single review with a diff from the start to the end of the range. There are no functional changes yet- the original `ctx` is also passed as the new `basectx`, which represents the first commit in the review range (similar to `qbase` in MQ parlance). Other functions will need the range of commits, but these deal with status or the diffs, so they only need the end points. Differential Revision: https://phab.mercurial-scm.org/D8306

phabricator: eliminate a couple of duplicate filectx lookups Differential Revision: https://phab.mercurial-scm.org/D8305