Mon, 09 Jan 2023 17:48:54 +0100 rust-narrow: fix loop that never loops stable
Raphaël Gomès <rgomes@octobus.net> [Mon, 09 Jan 2023 17:48:54 +0100] rev 49966
rust-narrow: fix loop that never loops This was caught by `clippy`. I guess the narrow tests leave something to be desired, since this previously only checked the first valid pattern.
Tue, 13 Dec 2022 12:50:52 +0100 dirstate: enforce holding the lock while doing any changes
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 13 Dec 2022 12:50:52 +0100] rev 49965
dirstate: enforce holding the lock while doing any changes This seems like a sensible sanity check. This already caught the issue in largefile. This will catch more issue when we start using similar context manager for operation other than the parent changes.
Fri, 27 Jan 2023 00:45:07 +0100 largefile: make sure we hold the lock when updating the second dirstate
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 27 Jan 2023 00:45:07 +0100] rev 49964
largefile: make sure we hold the lock when updating the second dirstate The largefile extension uses a second dirstate file (and object) to track some states. In some situations, it is lazily updated when needed. These operations might not have the lock taken. This means they might conflict and race with other ongoing operations. So we now take the lock to do these operations. This was caught by the next commit.
Thu, 26 Jan 2023 15:19:39 +0100 dirstate: rename `@requires_no_parents_change` too
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 26 Jan 2023 15:19:39 +0100] rev 49963
dirstate: rename `@requires_no_parents_change` too This match the rename of the context manager.
Thu, 26 Jan 2023 15:17:29 +0100 dirstate: rename `@requires_parents_change` to `@requires_changing_parents`
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 26 Jan 2023 15:17:29 +0100] rev 49962
dirstate: rename `@requires_parents_change` to `@requires_changing_parents` This match the rename of the context manager.
Tue, 13 Dec 2022 12:10:37 +0100 dirstate: write dirstate on successful exit of changing_parents context
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 13 Dec 2022 12:10:37 +0100] rev 49961
dirstate: write dirstate on successful exit of changing_parents context This is the first step toward having more sensible and predicatable write patterns for the dirstate. Having better write/rollback patterns will greatly reduce and clarify the needs to backup the dirstate.
Wed, 25 Jan 2023 19:12:31 +0100 dirstate: rename parentchange to changing_parents
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 25 Jan 2023 19:12:31 +0100] rev 49960
dirstate: rename parentchange to changing_parents Since the new argument breaks the API anyway, we can rename it to a better name. The previous name `parentchange` might be seen as something active, a function that would directly change the parents, however this is just a context manager to frame the operation that will change the parents and adjust the dirstate content accordingly. In addition, the future sister method that will be about changes to tracking and files would have a hard time fitting in the same naming scheme in a clear way. The new naming uses a clear prefix will make it more distinct from other dirstate methods and easier to extend with other similar contexts.
Wed, 25 Jan 2023 18:46:20 +0100 dirstate: pass the repo to the `changeparent` method
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 25 Jan 2023 18:46:20 +0100] rev 49959
dirstate: pass the repo to the `changeparent` method If we want the context to be responsible for writing (and we want it), we need to have access to a localrepository object. So we now requires a localrepository object as an argument to this context manager.
Tue, 13 Dec 2022 10:00:04 +0100 dirstate: warn about non-explicitly rolledback parent-change
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 13 Dec 2022 10:00:04 +0100] rev 49958
dirstate: warn about non-explicitly rolledback parent-change Now that the invalidation is dealt with by the context manager itself, we should no longer need this in the unlocking code. We start with issuing a warning if this is the case before actually dropping this code later.
Tue, 13 Dec 2022 11:39:44 +0100 dirstate: invalidate changes when parent-change fails
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 13 Dec 2022 11:39:44 +0100] rev 49957
dirstate: invalidate changes when parent-change fails When an error occurs during changing parents, we should invalidate all dirstate modifications and reload the dirstate. This is currently done by a `unlock` callback on the `wlock`. To fix this anomaly, we start dealing with the error directly in the context manager and its potential nesting. The "hard" part is to make sure that, when the parent-change context are nested, we and higher level nesting do not continue to use the invalidated dirstate. We introduce dedicated code to enforce that.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 tip