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.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 tip