Thu, 23 Feb 2023 15:16:40 +0100 delta-find: adjust the default candidate group chunk size
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Feb 2023 15:16:40 +0100] rev 50204
delta-find: adjust the default candidate group chunk size We move from 10 to 20 as the default as some usage in the wild saw a small degradation in storage quality when using `10`.
Tue, 07 Feb 2023 10:27:21 +0100 record: extract a closure to the module level
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 07 Feb 2023 10:27:21 +0100] rev 50203
record: extract a closure to the module level This clean up is almost as gratuituous as this closure was.
Tue, 07 Feb 2023 10:16:25 +0100 record: drop a now useless overlay that grab the lock
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 07 Feb 2023 10:16:25 +0100] rev 50202
record: drop a now useless overlay that grab the lock Since 28dfb2df4ab9, commit grab the wlock and the extra layer grabing the lock in record is no longer needed. We clean up the code to make this simpler (and add a small assert for extra security against future change).
Fri, 24 Feb 2023 03:03:54 +0100 bundlerepo: fix string interpolation
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 24 Feb 2023 03:03:54 +0100] rev 50201
bundlerepo: fix string interpolation Matt Harbison is saying we cannot `%s` a type into a byte string and that seems reasonable.
Thu, 23 Feb 2023 23:05:51 +0100 bundlerepo: apply phase data stored in the bundle instead of assuming `draft`
Matt Harbison <matt_harbison@yahoo.com>, Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Feb 2023 23:05:51 +0100] rev 50200
bundlerepo: apply phase data stored in the bundle instead of assuming `draft` The phase information contained in the changegroup part and the explicit `phase-heads` part are now taken in account. Initial changes and test by Matt Harbison, code rework by Pierre-Yves David.
Thu, 23 Feb 2023 19:07:58 +0100 bundlerepo: handle changegroup induced phase movement in the associated method
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Feb 2023 19:07:58 +0100] rev 50199
bundlerepo: handle changegroup induced phase movement in the associated method These movement comes from handling the changegroup part, so we keeps the code grouped. This will be important when handling more part (and more changegroup part in the future) This induce a small code duplication, but it does not looks terrible.
Thu, 23 Feb 2023 19:06:24 +0100 bundlerepo: move most attribute declaration earlier in __init__
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Feb 2023 19:06:24 +0100] rev 50198
bundlerepo: move most attribute declaration earlier in __init__ The expected attribute are clearer this way. The bundle handling code is responsible for setting most of it.
Thu, 23 Feb 2023 19:04:44 +0100 bundlerepo: move the handling of bundl1 in its own method
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Feb 2023 19:04:44 +0100] rev 50197
bundlerepo: move the handling of bundl1 in its own method This should make the overall flow simpler to follow.
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.
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -24 +24 +50 +100 +300 +1000 tip