Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 24 Aug 2021 21:08:09 +0200] rev 47940
dirstate: drop the deprecated `normal` method
The method was deprecated in 5.9.
Differential Revision: https://phab.mercurial-scm.org/D11344
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 24 Aug 2021 22:07:50 +0200] rev 47939
dirstate: also wrap the new method in `dirstatenonnormalcheck`
The goal of this is to make sure we set the data right, so we need to make sure
it run after the new method, that we actually call, in addition to the old one,
that we no longer call.
Differential Revision: https://phab.mercurial-scm.org/D11343
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 20 Aug 2021 16:12:33 +0200] rev 47938
dirstatemap: also discard item from sets
This seems more consistent to do that. I don't think any test was actually
barking about it, but the code feels a bit more robust now.
Differential Revision: https://phab.mercurial-scm.org/D11332
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 16 Jul 2021 18:25:01 +0200] rev 47937
dirstatemap: drop unused internal constant definition
All that logic now moved within the DirstateItem itself, so we can finally drop
this implementation details from the "higher" level.
Differential Revision: https://phab.mercurial-scm.org/D11331
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 16 Jul 2021 18:12:27 +0200] rev 47936
dirstate-item: add dedicated "legacy" constructor for `addfile` case
This way the internal details of how a DirstateItem is encoded is encapsulated
within the DirstateItem. This will finally give use some latitude to change the
data we store in a DirstateItem.
The addfile logic will likely be rewritten eventually and these dedicated
constructor can be removed at that time.
In the mean-time this should help with hiding internal details of DirstateItem
and to migrate it to new internal storage and logic.
Differential Revision: https://phab.mercurial-scm.org/D11330
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 16 Jul 2021 17:32:40 +0200] rev 47935
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
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 16 Jul 2021 17:29:16 +0200] rev 47934
dirstatemap: use the default code to handle "added" case
This one is very easy too.
Differential Revision: https://phab.mercurial-scm.org/D11328
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 16 Jul 2021 17:23:40 +0200] rev 47933
dirstatemap: use the default code to handle "removed" case
This one is very easy.
Differential Revision: https://phab.mercurial-scm.org/D11327
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 16 Jul 2021 17:20:17 +0200] rev 47932
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
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 16 Jul 2021 17:14:56 +0200] rev 47931
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
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 16 Jul 2021 17:10:52 +0200] rev 47930
dirstatemap: use the default code to handle "possibly_dirty" case
This case is quite simple too
Differential Revision: https://phab.mercurial-scm.org/D11324
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 16 Jul 2021 17:08:41 +0200] rev 47929
dirstatemap: use the default code to handle normal entry
This case is quite simple.
Differential Revision: https://phab.mercurial-scm.org/D11323
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 16 Jul 2021 17:03:39 +0200] rev 47928
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
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 16 Jul 2021 16:29:16 +0200] rev 47927
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
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 16 Jul 2021 16:52:53 +0200] rev 47926
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
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 20 Aug 2021 22:35:52 +0200] rev 47925
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
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 16 Jul 2021 16:30:52 +0200] rev 47924
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
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 20 Aug 2021 18:11:49 +0200] rev 47923
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
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 20 Aug 2021 22:30:30 +0200] rev 47922
dirstate-item: fix Cext declaration of dm_nonnormal and dm_otherparent
These are property, not method.
Differential Revision: https://phab.mercurial-scm.org/D11316
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 20 Aug 2021 11:27:01 +0200] rev 47921
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
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 20 Aug 2021 11:23:52 +0200] rev 47920
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
Raphaël Gomès <rgomes@octobus.net> [Wed, 25 Aug 2021 15:15:19 +0200] rev 47919
branching: merge stable into default
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Mon, 02 Aug 2021 08:05:13 -0400] rev 47918
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
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sun, 01 Aug 2021 10:57:21 -0400] rev 47917
tests: rename test-clone-uncompressed.t
as clone --uncompressed is deprecated in favor of --stream
Differential Revision: https://phab.mercurial-scm.org/D11237
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Fri, 06 Aug 2021 16:27:17 -0400] rev 47916
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
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Fri, 06 Aug 2021 16:17:17 -0400] rev 47915
test: reduce noise, so the important bits stand out
Differential Revision: https://phab.mercurial-scm.org/D11264
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Tue, 24 Aug 2021 17:27:16 +0200] rev 47914
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
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Tue, 24 Aug 2021 17:27:16 +0200] rev 47913
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