Thu, 23 Feb 2023 19:02:01 +0100 bundlerepo: expliclty handing cg part from bundle2
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Feb 2023 19:02:01 +0100] rev 50196
bundlerepo: expliclty handing cg part from bundle2 We will handle other types of parts soon (phase-heads) so we need some cleanup first.
Thu, 23 Feb 2023 15:37:46 +0100 transaction: use the standard transaction mechanism to backup branch
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Feb 2023 15:37:46 +0100] rev 50195
transaction: use the standard transaction mechanism to backup branch Branch is a bit special : - It currently does not collaborate with the transaction (or any scoping) for writing (this is bad) - It can change without the lock being taken (it is protected by `wlock`) So we rely on the same mechanism as for the backup of the other dirstate file: - we only do a backup if we hold the wlock - we force a backup though the transaction Since "branch" write does not collaborate with the transaction, we cannot back it up "at the last minute" as we do for the dirstate. We have to back it up "upfront". Since we have a backup, the transaction is no longer doing its "quick_abort" and get noisy. Which is quite annoying. To work around this, and to avoid jumping in yet-another-rabbit-hole of "getting branch written properly", I am doing horrible things to the transaction in the meantime. We should be able to get this code go away during the next cycle. In the meantime, I prefer to take this small stop so that we stop abusing the "journal" and "undo" mechanism instead of the proper backup mechanism of the transaction. Also note that this change regress the warning message for the legacy fallback introduced in 2008 when issue902 got fixed in dd5a501cb97f (Mercurial 1.0). I feel like this is fine as issue 902 remains fixed, and this would only affect people deploying a mix of 15 year old Mercurial and modern mercurial, and using branch and rollback extensively.
Thu, 23 Feb 2023 04:53:34 +0100 transaction: no longer explicitly cache bookmarks
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Feb 2023 04:53:34 +0100] rev 50194
transaction: no longer explicitly cache bookmarks The transaction file generation is already dealing with the backup for this. So, no need to duplicate such backup.
Wed, 22 Feb 2023 18:58:02 +0100 transaction: no longer explicitly cache phaseroots
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 18:58:02 +0100] rev 50193
transaction: no longer explicitly cache phaseroots The transaction file generation is already dealing with the backup for this. So, no need to duplicate such backup.
Thu, 23 Feb 2023 04:28:24 +0100 narrow: enforce that narrow spec is written within a transaction
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Feb 2023 04:28:24 +0100] rev 50192
narrow: enforce that narrow spec is written within a transaction
Thu, 23 Feb 2023 04:42:17 +0100 narrow: write the narrow spec in a transaction during share
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Feb 2023 04:42:17 +0100] rev 50191
narrow: write the narrow spec in a transaction during share It will be simpler if all write happens within transaction.
Thu, 23 Feb 2023 04:36:19 +0100 narrow: open the transaction sooner when unbundling
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Feb 2023 04:36:19 +0100] rev 50190
narrow: open the transaction sooner when unbundling That way, the narrow spec changes will be done within a transaction.
Thu, 23 Feb 2023 04:35:16 +0100 narrow: write the narrow spec in a transaction during clone
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Feb 2023 04:35:16 +0100] rev 50189
narrow: write the narrow spec in a transaction during clone It will be simpler if all write happens within transaction.
Thu, 23 Feb 2023 03:28:44 +0100 narrow: drop the dedicated backup code
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Feb 2023 03:28:44 +0100] rev 50188
narrow: drop the dedicated backup code Now that the transaction manage the writes, we can simply use the transaction for backup. Some extra cleanup to ensure all changes happens within a transaction will be made in the next changesets.
Thu, 23 Feb 2023 03:25:44 +0100 narrow: delegate the dirstate's narrow spec writing to the transaction
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Feb 2023 03:25:44 +0100] rev 50187
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.
Thu, 23 Feb 2023 04:15:16 +0100 narrow: delegate the narrow spec writing to the transaction
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Feb 2023 04:15:16 +0100] rev 50186
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.
Thu, 23 Feb 2023 04:02:38 +0100 narrow: get the narrow patterns from the repository object instead of disk
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Feb 2023 04:02:38 +0100] rev 50185
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.
Thu, 23 Feb 2023 00:12:53 +0100 narrow: widden the lock context in `tracking`
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Feb 2023 00:12:53 +0100] rev 50184
narrow: widden the lock context in `tracking` The tracking configuration we modify must be read under lock. So we grab the lock sooner.
Thu, 23 Feb 2023 03:49:29 +0100 narrow: move `only_show` handling sooner in `tracked`
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Feb 2023 03:49:29 +0100] rev 50183
narrow: move `only_show` handling sooner in `tracked` This will help us to improve the locking scope in the `tracked` command.
Fri, 24 Feb 2023 13:23:15 +0000 tests: in test-fncache.t, be more tolerant to the "Killed" message format
Arseniy Alekseyev <aalekseyev@janestreet.com> [Fri, 24 Feb 2023 13:23:15 +0000] rev 50182
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
Thu, 23 Feb 2023 23:25:28 +0100 convert: use a priority queue for sorting commits, to make sorting faster
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 23 Feb 2023 23:25:28 +0100] rev 50181
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.
Mon, 28 Nov 2022 12:33:20 +0100 dirstate-v2: don't mmap the data file when on NFS stable
Raphaël Gomès <rgomes@octobus.net> [Mon, 28 Nov 2022 12:33:20 +0100] rev 50180
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.
Thu, 08 Dec 2022 16:38:39 +0100 rust-dirstate: trace append/no append to help debugging stable
Raphaël Gomès <rgomes@octobus.net> [Thu, 08 Dec 2022 16:38:39 +0100] rev 50179
rust-dirstate: trace append/no append to help debugging
Mon, 12 Dec 2022 16:38:05 +0100 rust: add debug log about skipping dirstate update stable
Raphaël Gomès <rgomes@octobus.net> [Mon, 12 Dec 2022 16:38:05 +0100] rev 50178
rust: add debug log about skipping dirstate update
Mon, 09 Jan 2023 15:17:48 +0100 test-dirstate: use more robust method to trigger a data-file append stable
Raphaël Gomès <rgomes@octobus.net> [Mon, 09 Jan 2023 15:17:48 +0100] rev 50177
test-dirstate: use more robust method to trigger a data-file append The previous method was fragile and somewhat flaky on fast machines.
Tue, 21 Feb 2023 13:26:07 -0500 typing: add the return type hint to pycompat.rangelist()
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Feb 2023 13:26:07 -0500] rev 50176
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.
Tue, 21 Feb 2023 13:24:12 -0500 typing: add type hints to pycompat.maplist()
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Feb 2023 13:24:12 -0500] rev 50175
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.
Wed, 22 Feb 2023 18:42:09 +0100 branching: merge stable into default
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 18:42:09 +0100] rev 50174
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`
Wed, 22 Feb 2023 18:10:26 +0100 transaction: tests we don't overwrite bookmark activation on abort stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 18:10:26 +0100] rev 50173
transaction: tests we don't overwrite bookmark activation on abort We actually do not! Great.
Wed, 22 Feb 2023 18:09:12 +0100 transaction: tests we don't overwrite updates on abort stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 18:09:12 +0100] rev 50172
transaction: tests we don't overwrite updates on abort spoiler: we do… /o\
Wed, 22 Feb 2023 18:07:34 +0100 transaction: tests we don't overwrite branch changes on abort stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 18:07:34 +0100] rev 50171
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‽
Wed, 22 Feb 2023 18:05:36 +0100 transaction: tests we don't overwrite tracking to changed file on abort stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 18:05:36 +0100] rev 50170
transaction: tests we don't overwrite tracking to changed file on abort spoiler: we do…
Wed, 22 Feb 2023 18:03:18 +0100 transaction: the base of a new test file checking transaction abort issue stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 18:03:18 +0100] rev 50169
transaction: the base of a new test file checking transaction abort issue See inline documentation for details. See other changesets for actual cases.
Wed, 22 Feb 2023 18:30:47 +0100 setup: support building from an ongoing merge stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 18:30:47 +0100] rev 50168
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.
Fri, 17 Feb 2023 16:48:11 +0000 rhg: in path_encode, simplify a bit more
Arseniy Alekseyev <aalekseyev@janestreet.com> [Fri, 17 Feb 2023 16:48:11 +0000] rev 50167
rhg: in path_encode, simplify a bit more Use the slices for `basename` and `ext` instead of dealing with offsets.
Fri, 17 Feb 2023 13:29:39 +0000 rhg: in path_encode, be a bit more conservative about memory usage
Arseniy Alekseyev <aalekseyev@janestreet.com> [Fri, 17 Feb 2023 13:29:39 +0000] rev 50166
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.
Thu, 16 Feb 2023 19:14:51 +0000 rhg: small refactor: stop using a magical constant "+ 1"
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 16 Feb 2023 19:14:51 +0000] rev 50165
rhg: small refactor: stop using a magical constant "+ 1" Instead, directly do what the "+ 1" was supposed to achive: call hash_encode.
Thu, 16 Feb 2023 19:03:17 +0000 rhg: in path_encode, use Vec directly instead of VecDest
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 16 Feb 2023 19:03:17 +0000] rev 50164
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.
Thu, 16 Feb 2023 19:00:56 +0000 rhg: in path_encode, split Dest into VecDest and MeasureDest
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 16 Feb 2023 19:00:56 +0000] rev 50163
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.
Thu, 16 Feb 2023 18:46:44 +0000 rhg: use generic DestArr in hash_mangle
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 16 Feb 2023 18:46:44 +0000] rev 50162
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.
Thu, 16 Feb 2023 18:45:23 +0000 rhg: in path_encode, make DestArr generic over its size
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 16 Feb 2023 18:45:23 +0000] rev 50161
rhg: in path_encode, make DestArr generic over its size
Thu, 16 Feb 2023 18:41:06 +0000 rhg: in path_encode add a DestArr type
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 16 Feb 2023 18:41:06 +0000] rev 50160
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.
Thu, 16 Feb 2023 18:29:52 +0000 rhg: reduce verbosity in path_encode by using a trait for writing
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 16 Feb 2023 18:29:52 +0000] rev 50159
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.
Thu, 16 Feb 2023 16:20:17 +0000 refactor: simplify code in rust version of path_encode
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 16 Feb 2023 16:20:17 +0000] rev 50158
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.
Mon, 20 Feb 2023 23:46:20 +0100 dirstate: phase-divergent update to 4e95341c89aa
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 23:46:20 +0100] rev 50157
dirstate: phase-divergent update to 4e95341c89aa Heptapod published the obsolete version of those.
Tue, 21 Feb 2023 22:25:20 +0100 dirstate: phase-divergent update to 65943224c184
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Feb 2023 22:25:20 +0100] rev 50156
dirstate: phase-divergent update to 65943224c184 Heptapod published the obsolete version of those.
Sun, 19 Feb 2023 03:21:12 +0100 dirstate: phase-divergent update to 3433723d1b9b
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 19 Feb 2023 03:21:12 +0100] rev 50155
dirstate: phase-divergent update to 3433723d1b9b Heptapod published the obsolete version of those.
Wed, 22 Feb 2023 03:42:36 +0100 dirstate: enforce change context for hacky_extension_update_file
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 03:42:36 +0100] rev 50154
dirstate: enforce change context for hacky_extension_update_file This was the last method not scoped yet
Wed, 22 Feb 2023 04:00:30 +0100 large-files: use a `changing_files` context when initializing the dirstate
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 04:00:30 +0100] rev 50153
large-files: use a `changing_files` context when initializing the dirstate We are obviously mutating the dirstate, so lets scope this mutation.
Wed, 22 Feb 2023 03:20:19 +0100 dirstate: enforce context set_clean and set_possibly_dirty
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 03:20:19 +0100] rev 50152
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
Wed, 22 Feb 2023 03:35:18 +0100 keyword: wrap dirstate mutation in `changing_files` context
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 03:35:18 +0100] rev 50151
keyword: wrap dirstate mutation in `changing_files` context This is the way.
Wed, 22 Feb 2023 03:34:48 +0100 keyword: wrap dirstate mutation in `changing_files` context
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 03:34:48 +0100] rev 50150
keyword: wrap dirstate mutation in `changing_files` context This is the way.
Tue, 21 Feb 2023 23:10:02 +0100 dirstate: enforce `running_status` context for calling `status`
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Feb 2023 23:10:02 +0100] rev 50149
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.
Mon, 20 Feb 2023 17:13:29 +0100 dirstate: have `running_status` warn when exiting with a dirty dirstate
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 17:13:29 +0100] rev 50148
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.
Wed, 22 Feb 2023 02:21:27 +0100 dirstate: have `running_status` write the dirstate when holding the lock
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 02:21:27 +0100] rev 50147
dirstate: have `running_status` write the dirstate when holding the lock This is simple and harmless.
Mon, 20 Feb 2023 16:57:10 +0100 dirstate: check that dirstate is clean at the initial context opening
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 16:57:10 +0100] rev 50146
dirstate: check that dirstate is clean at the initial context opening More checking that we are not doing anything weird.
Tue, 21 Feb 2023 22:32:04 +0100 dirstate: start tracking that we are within a `running_status` context
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Feb 2023 22:32:04 +0100] rev 50145
dirstate: start tracking that we are within a `running_status` context
Mon, 20 Feb 2023 15:28:08 +0100 dirstate: add documentation about the expectation of `running_status` context
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
Mon, 20 Feb 2023 14:55:16 +0100 contrib-perf: use `running_status` in `perf::status`
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.
Mon, 20 Feb 2023 17:16:52 +0100 large-files: also open the context in the subdirstate
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
Wed, 22 Feb 2023 00:23:06 +0100 large-files: use `running_status` in `mergeupdate`
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`
Wed, 22 Feb 2023 00:22:44 +0100 large-files: use `running_status` in `scmutiladdremove`
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.
Wed, 22 Feb 2023 00:24:47 +0100 large-files: open the transaction sooner in `scmutiladdremove`
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.
Wed, 22 Feb 2023 00:22:16 +0100 large-files: use `running_status` in `overriderevert`
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
Wed, 22 Feb 2023 00:21:57 +0100 large-files: use `running_status` in `updatestandinsbymatch`
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.
(0) -30000 -10000 -3000 -1000 -300 -100 -60 +60 +100 +300 +1000 tip