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

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

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

dirstate: directly call the dirstatemap in `set_untracked` This function is only called in two places: the deprecated "remove" method and in the new `set_untracked` method. So we simply inline the appropriate content in `set_untracked`, paving the way to dropping the deprecated code and its associated function. Differential Revision: https://phab.mercurial-scm.org/D11313

resources: narrow the try:except clause to minimum Otherwise this mind hides other import or attribute errors. Differential Revision: https://phab.mercurial-scm.org/D11312

merge with stable

hgwebdir: avoid systematic full garbage collection Forcing a systematic full garbage collection upon each request can serioulsy harm performance. This is reported as https://bz.mercurial-scm.org/show_bug.cgi?id=6075 With this change we're performing the full collection according to a new setting, `experimental.web.full-garbage-collection-rate`. The default value is 1, which doesn't change the behavior and will allow us to test on real use cases. If the value is 0, no full garbage collection occurs. Regardless of the value of the setting, a partial garbage collection still occurs upon each request (not attempting to collect objects from the oldest generation). This should be enough to take care of reference cycles that have been created by the last request (assessment of this requires changing the setting, not to be 1). In my experience chasing memory leaks in Mercurial servers, the full collection never reclaimed any memory, but this is with Python 3 and biased towards small repositories. On the other hand, as explained in the Python developer docs [1], frequent full collections are very harmful in terms of performance if lots of objects survive the collection, and hence stay in the oldest generation. Note that `gc.collect()` is indeed trying to collect the oldest generation [2]. This happens usually in two cases: - unwanted lingering objects (i.e., an actual memory leak that the GC cannot do anything about). Sadly, we have lots of those these days. - desireable long-term objects, typically in caches (not inner caches carried by repositories, which should be collected with them). This is a subject of interest for the Heptapod project. In short, the flat rate that this change still permits is probably a bad idea in most cases, and the default value can be tweaked later on (or even be set to 0) according to experiments in the wild. The test is inspired from test-hgwebdir-paths.py [1] https://devguide.python.org/garbage_collector/#collecting-the-oldest-generation [2] https://docs.python.org/3/library/gc.html#gc.collect Differential Revision: https://phab.mercurial-scm.org/D11204

obsolete: disable other evolution config options if createmarkers is off We used to raise an abort in this case, but recent changes to local clone command (377d8fc20e34) resulted in destrepo both caring about experimental.evolution config options and not initializing extensions. So imagine if you had evolve and allowdivergence enabled in your ~/.hgrc. Local clone stopped working after 377d8fc20e34 because evolve sets experimental.evolution=all, but only on srcrepo, for destrepo the extension is not initialized. It's possible to make local cloning work by initializing extensions for destrepo in some cases, but in other cases (e.g. allowdivergence in ~/.hgrc, evolve extension in original-repo/.hg/hgrc) it would still fail. In a discussion with Pierre-Yves David it was decided to simply force other evolution options to be false if createmarkers is not enabled. Differential Revision: https://phab.mercurial-scm.org/D11223