narrow: delegate the dirstate's narrow spec writing to the transaction This make it more transactional and will help us to simplify their backup. The implementation is not great, but it keep the patch simple as this is not the time for a larger refactoring yet.

narrow: delegate the narrow spec writing to the transaction This make it more transactional and will help us to simplify their backup. The implementation is not great, but it keep the patch simple as this is not the time for a larger refactoring yet.

narrow: get the narrow patterns from the repository object instead of disk Relying on disk data make the transactionally of this change complicated, so let us start reading data from other API instead.

narrow: widden the lock context in `tracking` The tracking configuration we modify must be read under lock. So we grab the lock sooner.

narrow: move `only_show` handling sooner in `tracked` This will help us to improve the locking scope in the `tracked` command.

tests: in test-fncache.t, be more tolerant to the "Killed" message format For example, on my box I'm seeing: $TESTTMP.sh: line 250: $pid Killed hg ci -qAm z

convert: use a priority queue for sorting commits, to make sorting faster To achieve this, we turn commit sorters into classes so they can encapsulate state. This reduces the sorting time from ~30s to ~10s on a 500k-commit prefix of a repo I tried to convert. (and probably reduces the time to sort the whole repo from many tens of minutes to minutes, but I didn't try that again) The date caching gets removed because priority queue already caches the key.

dirstate-v2: don't mmap the data file when on NFS `mmap` on NFS will trigger a SIGBUS when the mmap'ed file is deleted, which wouldn't work in our case. Also, the performance advantage of using mmap on NFS is debatable at best.

rust-dirstate: trace append/no append to help debugging

rust: add debug log about skipping dirstate update

test-dirstate: use more robust method to trigger a data-file append The previous method was fragile and somewhat flaky on fast machines.

typing: add the return type hint to pycompat.rangelist() Not bothering with the args, because there are a few overloads and only 2 callers in the codebase, one of which is a test.

typing: add type hints to pycompat.maplist() The typeshed hints define 5 overloads with an increasing number of parameters on the passed function, and then a catchall that ignores the argument list on the passed function and allows an `*iterators` arg. All of our uses are fulfilled by the 1 function + 1 iterable overload, but add the second overload as a hint in case it's needed in the future.

branching: merge stable into default This show that the recent changes on default fixed the issue with transaction overwriting content in `test-transaction-wc-rollback-race.t`

transaction: tests we don't overwrite bookmark activation on abort We actually do not! Great.

transaction: tests we don't overwrite updates on abort spoiler: we do… /o\

transaction: tests we don't overwrite branch changes on abort We actually do not! Great. …Why are doing a backup of the `branch` files at transaction creation then‽

transaction: tests we don't overwrite tracking to changed file on abort spoiler: we do…

transaction: the base of a new test file checking transaction abort issue See inline documentation for details. See other changesets for actual cases.

setup: support building from an ongoing merge Before this change the two parents from the merge would duplicate some command output and modify some others in a way python 3.11 chokes on.

rhg: in path_encode, simplify a bit more Use the slices for `basename` and `ext` instead of dealing with offsets.

rhg: in path_encode, be a bit more conservative about memory usage Use [shrink_to_fit] to match the previous behavior more closely, and potentially save (a tiny bit) of memory. FWIW, I suspect this is unnecessary, but this whole MR is about simplifying things while preserving any existing optimizations.

rhg: small refactor: stop using a magical constant "+ 1" Instead, directly do what the "+ 1" was supposed to achive: call hash_encode.

rhg: in path_encode, use Vec directly instead of VecDest No need to have a trivial wrapper over the type. There's nothing confusing about vec.write_bytes(...), after all.

rhg: in path_encode, split Dest into VecDest and MeasureDest Two separate types make the write semantics easier to understand because we can consider the two sinks separately. Having two independent compiled functions for size measurement and for actual encoding seems likely to improve performance, too. (and maybe we should get rid of measurement altogether) Getting rid of [Dest] also removes the ugly option rewrapping code, which is good.

rhg: use generic DestArr in hash_mangle This simplifies code a bit more, but comes with an extra memory copy in case [destlen == dest_vec.len()]. This is probably fine, but a follow-up change is removing that too.

rhg: in path_encode, make DestArr generic over its size

rhg: in path_encode add a DestArr type This is an implementation of Sink trait that writes into a fixed-size buffer on the stack, so identical to what was done before, but it makes the code of [hash_encode] easier to understand by dropping all these slice manipulations.

rhg: reduce verbosity in path_encode by using a trait for writing Hopefully this makes the code easier to read and understand and shorter overall. It also lets us later tweak the type we use as a [Sink], without having to change the encoding functions, including using two different types for size measurement and for the actual serialization.

refactor: simplify code in rust version of path_encode Moving the addition of '/' separator to the end of the loop makes the rest of the logic much simpler because the first iteration is no longer special.

dirstate: phase-divergent update to 4e95341c89aa Heptapod published the obsolete version of those.

dirstate: phase-divergent update to 65943224c184 Heptapod published the obsolete version of those.

dirstate: phase-divergent update to 3433723d1b9b Heptapod published the obsolete version of those.

dirstate: enforce change context for hacky_extension_update_file This was the last method not scoped yet

large-files: use a `changing_files` context when initializing the dirstate We are obviously mutating the dirstate, so lets scope this mutation.

dirstate: enforce context set_clean and set_possibly_dirty We don't want them called within a `changing_parents` context, but we still want them called within a context. So we update the decorator accordingly

keyword: wrap dirstate mutation in `changing_files` context This is the way.

keyword: wrap dirstate mutation in `changing_files` context This is the way.

dirstate: enforce `running_status` context for calling `status` Now that the context is working as intended and that the callers are updated. We can enforce it.

dirstate: have `running_status` warn when exiting with a dirty dirstate If running_status was started without the lock, all changes should have been explicitly written (with the lock) or invalidated before exiting the context.

dirstate: have `running_status` write the dirstate when holding the lock This is simple and harmless.

dirstate: check that dirstate is clean at the initial context opening More checking that we are not doing anything weird.

dirstate: start tracking that we are within a `running_status` context

dirstate: add documentation about the expectation of `running_status` context

contrib-perf: use `running_status` in `perf::status` This is the way.

large-files: also open the context in the subdirstate

large-files: use `running_status` in `mergeupdate`

large-files: use `running_status` in `scmutiladdremove` This is the way.

large-files: open the transaction sooner in `scmutiladdremove` We want it to encompass the status call.

large-files: use `running_status` in `overriderevert` This is the way

large-files: use `running_status` in `updatestandinsbymatch` This is the way.

large-files: wrap reposetup's status in a `running_status` context This is the way.

narrow: use `running_status` in `updateworkingcopy` This is the way.

status: use `running_status` in dirstate status This is the way.

status: pre-indent the dirstate status code This make the next changeset clearer.

dirstate: introduce a (noop) running_status context Let us start with a simplistic context so we can scope the appropriate code before adding more logic.

status: invalidate dirstate on LockError If we cannot take the lock, someone else is modifying the repository. Let us discard dirstate uncommitted data before exiting the status code. Having a clean dirstate after such operation seems safer. Strictly speaking, there is a small behavior change in the following situation: * process A call `status` outside of the `wlock` * process B grab the `wlock` * process A fails to acquires the lock to write status fixup * process B release the `wlock` *without touching the dirstate* * process A later grab the `wlock` * process A can write dirstate update from earlier `status` However this is a fairly hypothetical situation : * process A has to be raced * process B have to not update the dirstate * process A has to run another *unrelated* operation later. This seems rare enough to overlook. I am stating that the two operations in process A has to be unrelated. Otherwise, collecting status data outside of the lock to use them inside the lock is racy. Any other process could move things around (eg: the working copy) making the data collected during status irrelevantor even harmful. If such code exists, it should be fixed ASAP.

status: simplify the post status fixup phases With the wlock automatically discarding changes when applicable, we can simplify the code a bit. * we perform the fixup operation before trying to grab the lock to narrow the `try/except` * we no longer need to explicitly complare dirstate identities. We can trust the dirstate internal refresh for that. It would invalidate dirty data when needed. * detect still data invalidation by checking the dirty flag before and after taking the lock. Doing this is actually only necessary to issue the debug message, we could blindy trust the dirstate internal to ignore the `write` call on a non-dirty dirstate.

dirstate: cleanup the `_map` property cache The removed code was duplicating the effect of `@propertycache`. This is a gratuitous cleanup.

dirstate: only reload the dirstate when it may have changed This reinstall the equivalent of what the `filecache` was doing. However it does it at the dirstate level. There is a double motivation for this: - This avoid duplicating logic with the dirstate "identity" logic. - This increase the lifetime of the `dirstate` object, helping to implement change scoping.

dirstate: directly manage the dirstate property on localrepo Before we had: * the filecache layer on `localrepo` doing some caching * the dirstate having some internal invalidation/refresh machanism * the status code doing some identity validation. To clean this up, we are dropping the first item "localrepo `filecache`" from the equation in a favor of an approach integrated into the dirstate (second item) in the next changesets. This changeset will be a small windows where some things will be a bit slower. This will be fixed in the next changesets.

dirstate: factor the identity getting/setting code in the dirstate map We are doing the same things twice and we will add more logic in the next changesets. So lets start factoring things out now.

dirstate: use `cachestat` object for dirstatemap identity There is a class dedicated to this kind of cache check, let us use it. We will generalize this code in the next changesets, but we do the "behavior changing" pass on our own.

automv: lock the repository before searching for renames I detected this while debugging something else.

dirstate: distinct transaction callback from largefile This has not caused any issue so far because the large-files dirstate bypass the transaction logic. We might want to change that. In anyway, let us disarm this bug nest before it actually explode.

dirstate: track that changes are pending in a transaction Nothing is currently broken because if this, but this make the `_invalidated_context` attribute more accurate. Being more accurate here will help us later, when dealing with `status` call.

dirstate: add small asserts for double security We don't need this, but it does not hurt.

dirstate: simplify the invalidation management on context exit Since the `invalidate` call will directly reset the `_invalidated_context` attribut, we can simplify the code. In the same go, we move most of the logic out of the `finally` clause. It seems cleaner and safer. If we are handling an exception, we don't need the `write` code anyway.

dirstate: use the new `check_invalidated` decorator for `_changing` WeeeEEeee, less code.

dirstate: introduce a check_invalidated decorator This is a common need, so let us consolidate it to simplify the code.

dirstate: warn if dirty when starting an edition The dirstate should be clean before we start changing it. Otherwise we might write unrelated changes. Having a dirty dirstate laying around is also suspicious. This is similar to what we do when opening a new transaction, but this time this affect dirstate changes outside of a transaction.

large-files: make sure we write newly initialized standin file early Any changing context will have to initialized it before anything else. Not flushing the default (pre-change) content mean we would enter the changing context with a dirty dirstate, which is odd.

dirstate: mark `clear` and `rebuild` as `require_changing_parents` Yeah, more scoping!

dirstate: add a comment about the semantic of `dirstate.clear` This method is weird, lets flag it as such.

debugrebuildstate: wrap the operation in a `changing_parents` context This ismaybe a "changing_files" case? However this would be the only usage of `rebuild` outside a `changing_parents` context and this is a debug command, so lets not make the code base more complex because of that one command.

strip: use a `changing_parents` context for --keep update These are now properly scoped. note: it would be neat to reuse this in `hg rollback`.

mq: wrap the dirstate's rebuild in a `changing_parents` context This code is dealing with `qreshesh` failure. In that case the working copy will be left on the parent of the refreshed patch, so the parents are changing and `changing_parents` make sens.

lfconvert: use a `changing_parents` context to clear the dirstate Not sure if this is the right context, but it works and it is consistent with the other usages of `dirstate.clear`.

dirstate: mark the `copy` method as requiring a `changing_any` context This is used both when changing parents (e.g. merging with rename) and changing files (e.g. running `hg rename`).

dirstate: add a `require_changing_any` decorator We will need it for a couple of usecase (e.g `dirstate.copy`).

rebase: scope parent change into a changing_parents context If we are actually altering the working copy (i.e. we are not in memory), we should properly scope the working copy update.

dirstate: requires being in a `changing_parents` `context to set_parents` Enforcing proper operation scoping on all methods that mutate the dirstate will tighten correctness and reduce the risk of bugs. The context to use for this method is obvious, and all code was already compliant ☺

dirstate: invalidate on all exceptions Previously, we would miss SystemExit, KeyboardInterrupt etc. This "fix" on the bug tested in "test-largefiles-update.t" by preventing the precisely tested situation to happens at all. However this reveal a similar bug with a different timing. I have not been able to deal with that pre-existing bug so far. So I updated the test to point that out.

large-files: prepare a test for more changes The behavior around this test is about to change. We update the test to make it more robust and the changes clearer.

large-files: larger "changing_parents" context in mergeupdate override This since we are updating the lfdirstate early, it seems reasonable to include the full function in that scope.

large-files: use `hacky_extension_update_file` one more time This override is about merging and can be used in a `changing_parents` context. So lets use the method dedicated to hacky stuff when doing hacky stuff.

typing: disable `signature-mismatch` warnings on a few bytestr functions Recent versions of pytype complain about this, but it seems like expected behavior.

rust: upgrade minimum `rayon` dependency The 1.6.0 and 1.6.1 releases fixes a soundness issue and a performance issue that are both important to us, since both correctness and performance are paramount in the Rust extensions.

branching: merge with stable

test-chg: use a different log to avoid flakyness The test was deleting the log file to start anew. However a trailing working process might still be alive at this time, and recreate the very same log on exit. We see the trace of such worker in the expected content of server.log (see the trace modified by this patch). This is flaky because we don't know *when* the worker will write to the file and there is a race with the `hg init cached` command. A much simpler and reliable way to start anew without having such race is… to write to a different log file. No reuse → no conflict, no conflict → no race, no race → no flakiness.

dirstate-v2: complain early on docket name collision The alternative is that the dirstate gets deleted so the corruption persists and is hard to investigate. This happened to me in tests, where the dirstate names are taken from file, since the file got reverted. I expect this can also happen in prod with non-trivial probability (1/4 billion).

rhg: fix a bug in path_encode This makes rhg able to access long paths at the root of the tree just fine.

rhg: demonstrate a bug in path_encode The bug means that long filenames at the root of the tree are encoded incorrectly by rhg, so rhg crashes when trying to access them.

rhg: nicer error message

typing: add type hints to argument checking functions in cmdutil These might be surprising, since they can take strings instead of bytes. The way `AnyStr` works is that it must be all bytes or all str for any given invocation. The wildcard here will be the `opts` that get passed in- if the type is unknown and defaults to `Any`, there's no enforcement that the dict key type matches the additional args. But a lot of uses should be using `**opts` from the command method, which has a str key. The uses of these methods in this module are now typed because their internals force a specific type, and it can't just be inferred from the caller.

setup: further improve the error path for version retrieval This is a new take at the problem that 8d390a13474d tried to tackle. There was two issues after that previous improvement: - the 0.0+ version could survive a bit too long and reaching the installer version and staying there. - multiple use case where still failing. So the new code is better at: - always succeeding when running `make local` so that we can bootstrap a local version - no using that fallback outside of `make local` to avoid distribution of version with the buggy version number. The setup.py is a gigantic pile of spaghetti code, to the point where pastafarian pilgrim started knocking at its core. However I refrained from cleaning that up since the more to a `setup.cfg` means this code should be deleted soon™.