Sat, 21 May 2022 23:31:30 +0200 worker: stop relying on garbage collection to release memoryview
Manuel Jacob <me@manueljacob.de> [Sat, 21 May 2022 23:31:30 +0200] rev 49232
worker: stop relying on garbage collection to release memoryview On CPython, before resizing the bytearray, all memoryviews referencing it must be released. Before this change, we ensured that all references to them were deleted. On CPython, this was enough to set the reference count to zero, which results in garbage collecting and releasing them. On PyPy, releasing the memoryviews is not necessary because they are implemented differently. If it would be necessary however, ensuring that all references are deleted would not be suffient because PyPy doesn’t use reference counting. By using with statements that take care of releasing the memoryviews, we ensure that the bytearray is resizable without relying on implementation details. So while this doesn’t fix any observable bug, it increases compatiblity with other and future Python implementations.
Sat, 21 May 2022 22:24:02 +0200 worker: add docstring to _blockingreader
Manuel Jacob <me@manueljacob.de> [Sat, 21 May 2022 22:24:02 +0200] rev 49231
worker: add docstring to _blockingreader
Sat, 21 May 2022 22:22:19 +0200 worker: explain why pickle reading stream has to be unbuffered
Manuel Jacob <me@manueljacob.de> [Sat, 21 May 2022 22:22:19 +0200] rev 49230
worker: explain why pickle reading stream has to be unbuffered
Tue, 17 May 2022 13:53:14 +0100 bundle: quick fix to ludicrous performance penalty
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 17 May 2022 13:53:14 +0100] rev 49229
bundle: quick fix to ludicrous performance penalty We tried a `hg bundle --base ':(tip^)' --rev 'all()'` on a large repository and it spent 3 minutes on this 2 list comprehensions. This change remove this cost. There are still a lot of low hanging fruits as the command still take 30 seconds. However this is a trivial patch with a massive speedup so I'll just sent it.
Fri, 20 May 2022 14:27:46 +0200 deltas: add a debug-delta-find command to analyse delta search
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 20 May 2022 14:27:46 +0200] rev 49228
deltas: add a debug-delta-find command to analyse delta search See command documentation for details. For some reason, pytype is confused by our usage of None/deltainfo variable, so I had to quiet it.
Thu, 19 May 2022 23:39:42 +0100 deltas: add a `debug.revlog.debug-delta` config option enable output
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 19 May 2022 23:39:42 +0100] rev 49227
deltas: add a `debug.revlog.debug-delta` config option enable output This provide a way to enable the code introduced in the previous changeset. This will provide a large amount of output when applying a bundle with details about each delta "computation".
Thu, 19 May 2022 23:39:23 +0100 deltas: add code to display information about the result of `finddeltainfo`
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 19 May 2022 23:39:23 +0100] rev 49226
deltas: add code to display information about the result of `finddeltainfo` I have been looking into performance issue around pull and getting more information about the computation and time involved into applying each revision is very useful. There will be various way to use this new output, so I am introducing the code first.
Thu, 21 Apr 2022 11:32:51 +0200 test: update `test-sparse-revlog` output
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 21 Apr 2022 11:32:51 +0200] rev 49225
test: update `test-sparse-revlog` output This got changed at some point.
Wed, 25 May 2022 17:23:16 +0200 branching: fix wrong merge conflict resolution from 13dfad0f9f7a
Manuel Jacob <me@manueljacob.de> [Wed, 25 May 2022 17:23:16 +0200] rev 49224
branching: fix wrong merge conflict resolution from 13dfad0f9f7a 13dfad0f9f7a merged stable into default, but accidentally added the _blockingreader class from stable (but deindented) instead of merging the changes from stable (2fe4efaa59af) into the existing _blockingreader class. This resulted in the _blockingreader being there two times.
Thu, 19 May 2022 00:51:36 +0100 debugdeltachain: detect a special case where parents are "skipped"
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 19 May 2022 00:51:36 +0100] rev 49223
debugdeltachain: detect a special case where parents are "skipped" See inline comment for details, this is a case where the delta is neither against p1 or p2, Yet it is still a simple delta part of a simple chain. We now display them as `skip1/skip2` instead of `other`.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 tip