Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 15:28:08 +0100] rev 50144
dirstate: add documentation about the expectation of `running_status` context
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 14:55:16 +0100] rev 50143
contrib-perf: use `running_status` in `perf::status`
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 17:16:52 +0100] rev 50142
large-files: also open the context in the subdirstate
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 00:23:06 +0100] rev 50141
large-files: use `running_status` in `mergeupdate`
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 00:22:44 +0100] rev 50140
large-files: use `running_status` in `scmutiladdremove`
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 00:24:47 +0100] rev 50139
large-files: open the transaction sooner in `scmutiladdremove`
We want it to encompass the status call.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 00:22:16 +0100] rev 50138
large-files: use `running_status` in `overriderevert`
This is the way
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 00:21:57 +0100] rev 50137
large-files: use `running_status` in `updatestandinsbymatch`
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 00:19:00 +0100] rev 50136
large-files: wrap reposetup's status in a `running_status` context
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 00:41:27 +0100] rev 50135
narrow: use `running_status` in `updateworkingcopy`
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 17:26:41 +0100] rev 50134
status: use `running_status` in dirstate status
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 17:22:57 +0100] rev 50133
status: pre-indent the dirstate status code
This make the next changeset clearer.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 15:18:07 +0100] rev 50132
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Feb 2023 22:14:12 +0100] rev 50131
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Feb 2023 16:20:11 +0100] rev 50130
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Feb 2023 15:35:31 +0100] rev 50129
dirstate: cleanup the `_map` property cache
The removed code was duplicating the effect of `@propertycache`.
This is a gratuitous cleanup.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 01:08:25 +0100] rev 50128
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 01:04:55 +0100] rev 50127
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Feb 2023 15:10:12 +0100] rev 50126
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 00:53:51 +0100] rev 50125
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Feb 2023 22:17:33 +0100] rev 50124
automv: lock the repository before searching for renames
I detected this while debugging something else.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 23:46:20 +0100] rev 50123
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 16:31:36 +0100] rev 50122
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Feb 2023 17:43:43 +0100] rev 50121
dirstate: add small asserts for double security
We don't need this, but it does not hurt.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 15:58:17 +0100] rev 50120
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 15:52:55 +0100] rev 50119
dirstate: use the new `check_invalidated` decorator for `_changing`
W
eeeEEeee, less code.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Feb 2023 22:25:20 +0100] rev 50118
dirstate: introduce a check_invalidated decorator
This is a common need, so let us consolidate it to simplify the code.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 19 Feb 2023 03:21:12 +0100] rev 50117
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Feb 2023 03:22:51 +0100] rev 50116
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 14:06:15 +0100] rev 50115
dirstate: mark `clear` and `rebuild` as `require_changing_parents`
Yeah, more scoping!
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 11:37:02 +0100] rev 50114
dirstate: add a comment about the semantic of `dirstate.clear`
This method is weird, lets flag it as such.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 14:05:19 +0100] rev 50113
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 19 Feb 2023 02:50:46 +0100] rev 50112
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`.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 19 Feb 2023 02:47:28 +0100] rev 50111
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 11:37:05 +0100] rev 50110
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`.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 11:57:46 +0100] rev 50109
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`).
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 11:54:10 +0100] rev 50108
dirstate: add a `require_changing_any` decorator
We will need it for a couple of usecase (e.g `dirstate.copy`).
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 12:06:03 +0100] rev 50107
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 18 Feb 2023 04:10:08 +0100] rev 50106
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 ☺
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Feb 2023 00:10:20 +0100] rev 50105
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Feb 2023 01:09:11 +0100] rev 50104
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Feb 2023 00:32:40 +0100] rev 50103
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 19 Feb 2023 03:14:44 +0100] rev 50102
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.
Matt Harbison <matt_harbison@yahoo.com> [Sun, 19 Feb 2023 00:04:53 -0500] rev 50101
typing: disable `signature-mismatch` warnings on a few bytestr functions
Recent versions of pytype complain about this, but it seems like expected
behavior.
Raphaël Gomès <rgomes@octobus.net> [Thu, 16 Feb 2023 11:42:34 +0100] rev 50100
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 18 Feb 2023 02:39:32 +0100] rev 50099
branching: merge with stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 18 Feb 2023 01:21:51 +0100] rev 50098
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.
Arseniy Alekseyev <aalekseyev@janestreet.com> [Fri, 18 Nov 2022 13:51:40 +0000] rev 50097
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).
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 16 Feb 2023 14:56:59 +0000] rev 50096
rhg: fix a bug in path_encode
This makes rhg able to access long paths at the root of the tree just fine.
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 16 Feb 2023 14:54:34 +0000] rev 50095
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.
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 16 Feb 2023 14:43:46 +0000] rev 50094
rhg: nicer error message
Matt Harbison <matt_harbison@yahoo.com> [Tue, 14 Feb 2023 12:40:59 -0500] rev 50093
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 17 Feb 2023 16:45:36 +0100] rev 50092
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™.
Matt Harbison <matt_harbison@yahoo.com> [Tue, 14 Feb 2023 15:45:26 -0500] rev 50091
tag: move the prohibition of tagging the `null` rev up to the `wdir()` check
It makes sense to do these together, and avoid another revision lookup.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 17 Feb 2023 17:04:41 +0100] rev 50090
branching: merge with default
the first part of the fix is there
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 17 Feb 2023 14:00:39 +0100] rev 50089
dirstate: handle missing backup file on restoration
This is the stable counter part to
e358f6e0e50e.
Since 6.4 will stop writing undo.dirstate in some case (actually… at all), a
transaction created with 6.4 and recover/rolledback with 6.3 need to work to a
certain degreee. This changeset add the necessary bits so that we don't get a
traceback from 6..3 in this cases.