dirstatemap: use the default code to handle "added" case This one is very easy too. Differential Revision: https://phab.mercurial-scm.org/D11328

dirstatemap: use the default code to handle "removed" case This one is very easy. Differential Revision: https://phab.mercurial-scm.org/D11327

dirstatemap: use the default code to handle "clean-p2" case This simplify the conditionnal a bit since most of it is handled by the common code. Differential Revision: https://phab.mercurial-scm.org/D11326

dirstatemap: use the default code to handle "p2-tracked" case We juste have to do minor value adjustement and the default code will do the rest. This kind of change highglight that "clean_p2" is probably not the right name, for that value. However this is all thing to be figured out and cleaned up once are done moving logic at lower level. Differential Revision: https://phab.mercurial-scm.org/D11325

dirstatemap: use the default code to handle "possibly_dirty" case This case is quite simple too Differential Revision: https://phab.mercurial-scm.org/D11324

dirstatemap: use the default code to handle normal entry This case is quite simple. Differential Revision: https://phab.mercurial-scm.org/D11323

dirstatemap: conclude `reset_state` with logic using the new __init__ Now the DirstateItem can deal with most of the logic related to its initialization, our goal is to migrate the function to a more "unified" way were minimal processing is done early before more generic code gets into play. Nobody is calling this code yet, but this is about to change. Differential Revision: https://phab.mercurial-scm.org/D11322

dirstatemap: temporarily return early in `reset_state` We are about to migrate `addfile` to the new `DirstateItem__init__` and having these early return will the new series of patches to be clearer. Differential Revision: https://phab.mercurial-scm.org/D11321

dirstate-item: feed more information to `__init__` Instead of processing the "rich" value at the `dirstatemap` level, we can now directly pass them to the DirstateItem object. This will make the object free to store whatever its want and to implements it logic whatever its want. For now… we simply process the flag and store the same good old value. However this pave the way for doing things differently once the rest of dirstatemap code is updated. Nobody call this code yet. Differential Revision: https://phab.mercurial-scm.org/D11320

rust-dirstatemap: temporarily use `from_v1_data` in `addfile` We are about to change the `__init__` for `DirstateItem`. To make the transition easier, we move existing caller to `DirstateItem.from_v1_data`. The Rust dirstate map will need an overall once the durst settle anyway. Differential Revision: https://phab.mercurial-scm.org/D11319

dirstatemap: temporarily use `from_v1_data` in `addfile` We are about to change the `__init__` for `DirstateItem`. To make the transition easier, we move existing caller to `DirstateItem.from_v1_data`. Differential Revision: https://phab.mercurial-scm.org/D11318

dirstate-item: fix the declaration of the Cext `from_v1_meth` This method is apparently not called from anywhere since the declaration was garbage. We will start calling it in the next changeset. Differential Revision: https://phab.mercurial-scm.org/D11317

dirstate-item: fix Cext declaration of dm_nonnormal and dm_otherparent These are property, not method. Differential Revision: https://phab.mercurial-scm.org/D11316

dirstatemap: replace `removefile` by an explicit `entry.set_untracked()` All the other caller goes through `reset_state`, so we can safely have an explicit method on `DirstateItem` object. This means that all the logic to preserve the previous state (from p2, merged, etc) is now properly encapsulated within the DirstateItem. This pave the way to using different storage for these information. Differential Revision: https://phab.mercurial-scm.org/D11315

dirstate: forward `remove` call to newer `API` The `_remove` method was only called in the deprecated `remove` function. We merge the two and express it in terms of call to new API methods. Differential Revision: https://phab.mercurial-scm.org/D11314

Added signature for changeset 86a60679cf61

Added tag 5.9.1 for changeset 86a60679cf61

fix: again allow formatting the working copy while merging I forgot about unfinished merges (I think I was thinking only about unfinished merge conflicts) when I wrote https://phab.mercurial-scm.org/D11209. As a coworker (hg contributor dploch) reported to me, this led to `hg fix --working-dir` failing when you have an uncommitted merge. The fix is trivial: just move the assertion to just before the call to `scmutil.movedirstate()` where it actually matters. Differential Revision: https://phab.mercurial-scm.org/D11376

pyoxidizer: add arch to PyOxidizer MSIs This is the proper filename pattern. This filename format wasn't properly implemented when PyOxidizer took over Python 3 MSI generation in 603efb3845ba. Differential Revision: https://phab.mercurial-scm.org/D11359

pyoxidizer: pass arch to WiXInstaller() We just upgraded Windows automation to PyOxidizer 0.17.0. This version of PyOxidizer changed the behavior of WiX installers so installer architecture defaulted to "x64" (before it defaulted to the target of the pyoxidizer.exe binary). To allow controlling the architecture of the installer, the `arch` argument was added to `WiXInstaller`. This commit passes that argument in. Differential Revision: https://phab.mercurial-scm.org/D11358

contrib: install PyOxidizer 0.17.0 This pulls in some changes we want to improve Windows MSI installers. This will need separate enhancements to the pyoxidizer.bzl. But those will be handled in a separate changeset. Differential Revision: https://phab.mercurial-scm.org/D11357

packaging: reference proper output directory 9438e9b7321a changed the name of the PyOxidizer target, which changed the name of the output directory. The code changed by this patch wasn't properly updated by that changeset. This resulted in a run-time failure due to trying to read from a non-existent directory. This change should fix the building of Python 3 Inno installers. Differential Revision: https://phab.mercurial-scm.org/D11356

packaging: pass extra_pyoxidizer_vars only to pyoxidizer Before, we would attempt to call a function (build_installer_py2exe) that didn't accept this keyword argument. This was preventing the building of py2exe installers. Differential Revision: https://phab.mercurial-scm.org/D11355

hg: don't attempt to extend `sys.path` with the user site without `APPDATA` This variable is created by the system and *should* be available, but test-lfs-bundle.t has a test where it is explicitly unset. It wasn't caught before because prior to 95af358fcdfe, it was limited to the py2exe binary. As a precaution, fix both that and the pyoxidizer case that was causing the test to fail. Differential Revision: https://phab.mercurial-scm.org/D11354

ci: only run the phabricator step if the previous on succeeded It seems like f6879956a386 regressed the intended behavior. Differential Revision: https://phab.mercurial-scm.org/D11342

branching: merge stable into default

store: return just one filename in walk functions Various walk functions return `(revlog_type, decoded, encoded)` where decoded could be None. But no-one cares about `encoded` and expects `unencoded` to be present, except verify (because this can only happen with old repo formats). Simplify all this by either failing outright if a decoding a filename fails (instead of almost certainly failing with a type error due to treating None as a bytes), or skipping the filename but providing in an out argument for hg verify. Differential Revision: https://phab.mercurial-scm.org/D11248

tests: rename test-clone-uncompressed.t as clone --uncompressed is deprecated in favor of --stream Differential Revision: https://phab.mercurial-scm.org/D11237

debugrebuildfncache: add a cheaper option to rebuild the fncache On my repository, debugrebuildfncache takes 5-10min with the lock. With the flag added in this commit, it takes 10s. The tradeoff is that it only recovers from certain kinds of corruptions. It is intended to to recover faster from fncaches broken by a revlog split during a transaction that ends up being rolled back. Differential Revision: https://phab.mercurial-scm.org/D11265

test: reduce noise, so the important bits stand out Differential Revision: https://phab.mercurial-scm.org/D11264

wireprotov1peer: update all rpcs to use the new batchable scheme If desired, we could keep the future class and the function that upgrades an old style rpc instead of a new style, for extensions. Differential Revision: https://phab.mercurial-scm.org/D11212

wireprotov1peer: simplify the way batchable rpcs are defined The scheme with futures/generator is confusing due to the way communication is done by side effects, especially with two different "future" objects. Just returning a request and a function to read the response is easier to understand. There are tests failures with the largefiles extension due to it aliasing one rpc to another one, which gets fixed in the next commit. Differential Revision: https://phab.mercurial-scm.org/D11211