Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 03:35:18 +0100] rev 50200
keyword: wrap dirstate mutation in `changing_files` context
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 03:34:48 +0100] rev 50199
keyword: wrap dirstate mutation in `changing_files` context
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Feb 2023 23:10:02 +0100] rev 50198
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 17:13:29 +0100] rev 50197
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 02:21:27 +0100] rev 50196
dirstate: have `running_status` write the dirstate when holding the lock
This is simple and harmless.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 16:57:10 +0100] rev 50195
dirstate: check that dirstate is clean at the initial context opening
More checking that we are not doing anything weird.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Feb 2023 22:32:04 +0100] rev 50194
dirstate: start tracking that we are within a `running_status` context
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 15:28:08 +0100] rev 50193
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 50192
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 50191
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 50190
large-files: use `running_status` in `mergeupdate`
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 00:22:44 +0100] rev 50189
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 50188
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 50187
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 50186
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 50185
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 50184
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 50183
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 50182
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 50181
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 50180
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 50179
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 50178
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 50177
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 50176
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 50175
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 50174
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 50173
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 50172
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 50171
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 50170
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 50169
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 50168
dirstate: use the new `check_invalidated` decorator for `_changing`
WeeeEEeee, less code.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Feb 2023 22:25:20 +0100] rev 50167
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 50166
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 50165
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 50164
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 50163
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 50162
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 50161
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 50160
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 50159
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 50158
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 50157
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 50156
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 50155
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 50154
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 50153
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 50152
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 50151
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 50150
typing: disable `signature-mismatch` warnings on a few bytestr functions
Recent versions of pytype complain about this, but it seems like expected
behavior.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 18 Feb 2023 02:39:32 +0100] rev 50149
branching: merge with stable
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 16 Feb 2023 14:56:59 +0000] rev 50148
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 50147
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 50146
rhg: nicer error message
Matt Harbison <matt_harbison@yahoo.com> [Tue, 14 Feb 2023 12:40:59 -0500] rev 50145
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.
Matt Harbison <matt_harbison@yahoo.com> [Tue, 14 Feb 2023 15:45:26 -0500] rev 50144
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 50143
branching: merge with default
the first part of the fix is there
Dan Villiom Podlaski Christiansen <dan.villiom.podlaski.christiansen@sallinggroup.com> [Fri, 27 Jan 2023 17:30:51 +0100] rev 50142
tests: remove unnecessary --traceback argument
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Feb 2023 04:49:35 +0100] rev 50141
dirstate: remove the dedicated backup logic
When alone, the dirstate can now take care of its commit/rollback pattern
itself.
When in a transaction, the transaction deal with commit/rollback pattern quite
fine.
Why did you have a dedicated backup logic?
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Feb 2023 04:02:36 +0100] rev 50140
localrepo: stop doing special dirstate backup at transaction open
Since the dirstate writes are already managed by the transaction, we already do
a backup of the dirstate when necessary (and even trigger one to keep `hg
rollback` happy).
We needs some special code to deal with the initial empty checkout, but it is
not too complicated.
Managing variable filename (as dirstate-v2 uses) at the "journalfile" level, is
complex and fragile (which is consistent with the fact these files are not
journal…). If we no longer do it, our life is significantly simpler.
In some sense, we apply the xkcd-1134¹ solution to our savebackup/restorebackup
problem.
[1] https://xkcd.com/1134/
(the change to test-hardlink are expect as decreasing the number of duplicated
backup drive the hardlink count down)
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Feb 2023 11:42:43 +0100] rev 50139
localrepo: "blindly" do a dirstate backup at the end of the transaction
Having the file backup mechanism dealing with file backup as benefit. So lets
move closer to that.
The fact `hg rollback` even needs this is sad. I hope to have the time to
implement one of the alternative soon.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Feb 2023 17:12:21 +0100] rev 50138
test-hardlink: stop explicitly listing `undo.dirstate`
The files is on its way out.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Feb 2023 04:04:40 +0100] rev 50137
localrepo: enforce a clean dirstate when the transaction open
This is important to simplify the backup process. This also seems like a quite
reasonable expectation. See inline documentation for details.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Feb 2023 10:43:22 +0100] rev 50136
dirstate: explicitly backup the datafile
Since the transaction does not know about this file, we need to explicitly mark
it for backup before touching it.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Feb 2023 04:41:38 +0100] rev 50135
mq: write the dirstate before stripping
I am not certain why it is dirty (probably the `repo.setparent` call a right
before. However I know we need it flushed before the repository starts to be
stripped.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Feb 2023 03:08:00 +0100] rev 50134
dirstate: simplify the shelve hack to not go through the disk
We already have the data in memory, so why not simply keep the data in memory?
This avoid abusing the `savebackup/restorebackup` logic and will make our life
easier.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Feb 2023 02:44:07 +0100] rev 50133
dirstate: detect potential fishy transaction patterns while changing
If we rely on the transaction more, we should be more careful about the
transaction. Adding extra security seems reasonable.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Feb 2023 02:34:54 +0100] rev 50132
dirstate: generalize the dirstate's invalidation on transaction abort
The previous code was too specific, we should add the invalidation at next to
the `addfilegenerator` in the `write` call.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Feb 2023 02:22:13 +0100] rev 50131
dirstate: simplify some methods' decorator
Since `changing_parents` and `changing_files` are mutually exclusive, having
both `@requires_changing_files` and `@requires_not_changing_parents` on a method
is redundant.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Feb 2023 02:19:56 +0100] rev 50130
dirstate: document the functions that need consolidation
They are more functions that make the dirstate dirty but does not currently
enforce a clean change scoping, we add comments in front of each of them so
clarify this. There is no urgency to it, but the world will be a better place
when all of them have proper scoping in place.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Feb 2023 05:03:28 +0100] rev 50129
dirstate: make `restorebackup` more robust when it is a noop
If there are no data_file, we might not be able to determine its filename.
Which can be safely ignored.
(all this code is on the way out anyway)
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Feb 2023 00:33:15 +0100] rev 50128
dirstate-guard: remove the feature
The dirstate guard duplicated some of the logic already implemented in the
transaction (and now the changing_* context).
However the feature was incomplete, for example, living only in memory meant we
could not recover from the hardest crash. In addition this duplicated with the
transaction logic meant things could go out of sync or step on each other.
Removing the feature now that we no longer needs it seems the safest.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Feb 2023 00:14:21 +0100] rev 50127
rollback: remove the dirstateguard usage
Thanks to the previous changeset, we no longer needs it.
begone !
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Feb 2023 10:00:59 +0100] rev 50126
rollback: explicitly skip dirstate rollback when applicable
instead of letting the transaction logic overwrite the dirstate and then
overwrite that overwrite with a backup. We simply do not restore the dirstate
related file during the _playback call.
This open the way to removing the last dirstate guard usage.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Feb 2023 00:26:24 +0100] rev 50125
rollback: detect "parentgone" case earlier
Detecting this earlier will help us to affect the rollback process sooner, which
will help the next changesets.
To keep things simple, we degrade the behavior a bit when the `undo.desc` is
missing. However since `hg rollback` is not supposed to be used and the
`undo.desc` file have been introduced in mercurial 1.6 (2010). I think this is
an acceptable evil.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Feb 2023 23:39:10 +0100] rev 50124
rollback: avoid a `hg commit --addremove` at a critical point
The rollback behavior around `hg commit --addremove` has changed slightly. It
does not really matters here but keeping that variant out of the way cannot
hurt.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Feb 2023 20:48:51 +0100] rev 50123
rollback: display some graphlog before/after a test piece
This make the situation clearer.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Feb 2023 20:47:08 +0100] rev 50122
rollback: show that the safety works in a associated test
That test section is checking that --force is overcoming the safety check,
however we did not check that the safety properly detect the situation.
We now do for clarity.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 14 Feb 2023 00:40:27 +0100] rev 50121
dirstate-guard: remove its usage in `backout`
We can simply replace it with a transaction.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 14 Feb 2023 00:42:00 +0100] rev 50120
dirstate-guard: remove the usage in `import`
It is now redundant with the transaction spawning the same scope.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 14 Feb 2023 00:39:49 +0100] rev 50119
dirstate-guard: replace a usage in `rebase` with a transaction
Opening the transaction sooner will provide us with the same benefit.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 14 Feb 2023 00:31:41 +0100] rev 50118
dirstate-guard: remove usage in `rebase`
Now that the dirstate change and write are clearer, it does not seems we need to
use a dirstate-guard here anymore. The transaction already wrap the full
operation.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 14 Feb 2023 00:31:23 +0100] rev 50117
dirstate-guard: remove it usage in `mq`
The code it covered is also covered by a `changing_parents` context.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 26 Jan 2023 17:46:54 +0100] rev 50116
dirstate: enforce the use of `changing_files` context to change tracking
Now that everything is using the new context, we can start enforcing its usage.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 13 Dec 2022 03:55:14 +0100] rev 50115
dirstate: warn if we write to the dirstate without holding the wlock
Writing the dirstate without holding the wlock can race with other update and
overwrite important change. The comment questionning the current state of
things was right, we should the `wlock` should always cover the dirstate.
(Yes, this is me, agreeing with myself, half a decade later).
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Feb 2023 21:31:37 +0100] rev 50114
dirstate: avoid transaction backup/restore if we do not hold the lock
Doing overwriting the dirstate content without holding the lock is a recipe for
disaster.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 13 Dec 2022 09:59:22 +0100] rev 50113
dirstate: issue a developer warning on implicit write on wlock release
Our goal is to get rid of all these to clarify the writing pattern, so it is
time to warn about this (and later, forbid it).
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Feb 2023 23:29:04 +0100] rev 50112
status: fix post status invalidation
If the dirstate changed under us, we should throw away what we have a reload it,
should we not ?
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Feb 2023 23:28:20 +0100] rev 50111
status: fix post status writing
With dirstate-v2, the status process itself might update internal states. So we
make sure this get written on disk
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 15 Dec 2022 02:54:06 +0100] rev 50110
dirstate: use `dirstate.change_files` to scope the change in `shelve`
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 15 Dec 2022 03:04:58 +0100] rev 50109
dirstate: use `dirstate.change_files` to scope the change in `unshelve`
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 15 Dec 2022 06:22:23 +0100] rev 50108
shelve: adjust what happens in some `changing_parents` context
It seems like the rest is more about changing tracked_files, so we let start
with moving them out of the `changing_parents` contexts.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 13 Feb 2023 23:29:30 +0100] rev 50107
dirstate: use `dirstate.change_files` to scope the change in `lfconvert`
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 05 Feb 2023 12:09:52 +0100] rev 50106
largefiles: rely on main scoping for writing dirstate in `markcommitted`
Yeah, cleaner code.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 05 Feb 2023 12:05:23 +0100] rev 50105
largefiles: rely on main scoping for writing dirstate in `mergeupdate`
Yeah, cleaner code.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 04 Feb 2023 16:54:46 +0100] rev 50104
largefiles: rely on the higher level `changing_giles` in `mergerecordupdates`
Now that context open on the main dirstate also affect the underlying one, we
can skip opening our own in `mergerecordupdates`
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 14 Dec 2022 00:46:58 +0100] rev 50103
dirstate: use wlock and `dirstate.change_files` to scope the change in `mq`
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 25 Jan 2023 12:51:26 +0100] rev 50102
subrepo: use `changing_files` context in subrepository code
This is better, not ideal, but better.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 04 Feb 2023 12:14:19 +0100] rev 50101
subrepo: let black expand some call on multiple lines early
newer version of black are righfully doing this, so I apply it before more
semantic change to reduce noise in the next changeset.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 14 Dec 2022 00:43:24 +0100] rev 50100
dirstate: use `dirstate.change_files` to scope the change in `import`
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 14 Dec 2022 00:52:06 +0100] rev 50099
dirstate: use `dirstate.change_files` to scope the change in `automv`
This is... mostly... the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 14 Dec 2022 00:47:22 +0100] rev 50098
dirstate: use `dirstate.change_files` to scope the change in `amend`
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 25 Jan 2023 12:46:46 +0100] rev 50097
dirstate: use the `changing_files` context in the `keyword` demo
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 25 Jan 2023 12:56:26 +0100] rev 50096
dirstate: wrap repository change in appropriate context in `test-context`
We need the `wlock` (to add files), the `lock` (to commit), a `transaction` (to
commit) and a `changing_files` context (to add files).
Strictly speaking, we could let the commit take the `lock` and create a
`transaction`, but it seems more consistent that way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 25 Jan 2023 12:57:52 +0100] rev 50095
dirstate: use wlock and changing_files context in `test-revlog-ancestry`
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 13 Dec 2022 15:01:59 +0100] rev 50094
dirstate: use `dirstate.change_files` to scope the change in `revert`
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 25 Jan 2023 12:46:22 +0100] rev 50093
dirstate: use `dirstate.change_files` to scope the change in `gpg`
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 13 Dec 2022 16:57:41 +0100] rev 50092
dirstate: use `dirstate.change_files` to scope the change in `tag`
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 31 Jan 2023 00:05:12 +0100] rev 50091
dirstate: use `dirstate.change_files` to scope the change in `rename`
This is the way, unless we are not actually touching the working copy.
In such cases we don't need to do something.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 31 Jan 2023 00:08:53 +0100] rev 50090
dirstate: use `dirstate.change_files` to scope the change in `copy`
This is the way, unless we are not actually touching the working copy.
In such cases we don't need to do something.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 13 Dec 2022 16:29:30 +0100] rev 50089
dirstate: use `dirstate.change_files` to scope the change in `remove`
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 13 Dec 2022 16:27:57 +0100] rev 50088
dirstate: use `dirstate.change_files` to scope the change in `forget`
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 13 Dec 2022 15:07:32 +0100] rev 50087
dirstate: use `dirstate.change_files` to scope the change in `addremove`
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 13 Dec 2022 12:57:38 +0100] rev 50086
dirstate: use `dirstate.change_files` to scope the change in `add`
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Feb 2023 11:51:58 +0100] rev 50085
commit: use `dirstate.change_files` to scope the associated `addremove`
This was significantly more complicated than I expected, because multiple
extensions get in the way.
I introduced a context that lazily open the transaction and associated context
to work around these complication. See the inline documentation for details.
Introducing the wrapping transaction remove the need for dirstate-guard (one of
the ultimate goal of all this), and slightly affect the result of a `hg
rollback` after a `hg commit --addremove`. That last part is deemed fine. It
aligns the behavior with what happens after a failed `hg commit --addremove` and
nobody should be using `hg rollback` anyway.
The small output change in the test come from the different transaction timing
and fact the transaction now backup the dirstate before the addremove, which
might mean "no file to backup" when the repository starts from an empty state.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 05 Feb 2023 15:38:23 +0100] rev 50084
commit: move the addremove logic around to make the next changeset clearer
Lets do the noise now, without changing any thing. So the new changeset can
focus on the actual semantic changes.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Feb 2023 10:46:46 +0100] rev 50083
largefiles: link the core dirstate._changing context to the lfdirstate one
This will be much cleaner and safer to make sure the two dirstates are in sync.
This way, the large-files dirstate will simply inherit the state of the main
dirstate, so if the core code does the right thing, the large-files code should
be right too.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 26 Jan 2023 17:44:27 +0100] rev 50082
dirstate: add a context for tracking files change
Let us start to use it. We will enforce it later.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 13 Feb 2023 21:51:45 +0100] rev 50081
dirstate: invalidate the dirstate change on transaction failure
If the change context lives inside a transaction, the change are not flushed to
disk on exit as this is delegated to the transaction. As a result we should
also delegate the part that do cleanup on failure.
The issue was caught by tests with other change, but it seems useful to fix this
as soon as possible.