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