Wed, 13 Mar 2024 16:22:13 -0300 obsutil: sort metadata before comparing in geteffectflag() stable
Anton Shestakov <av6@dwimlabs.net> [Wed, 13 Mar 2024 16:22:13 -0300] rev 51502
obsutil: sort metadata before comparing in geteffectflag() This is probably less important now that we dropped Python 2. We do still support Python 3.6 though, and the dictionaries aren't ordered there either (that was a big change that came with 3.7). Still, maybe it's a good idea to sort metadata explicitly.
Mon, 11 Mar 2024 11:11:34 +0100 tests: disable revlog compression in test-generaldelta.t (issue6867) stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 11 Mar 2024 11:11:34 +0100] rev 51501
tests: disable revlog compression in test-generaldelta.t (issue6867) The revlog compression makes a lot of numbers unstable. Since checking revlog compression is not the goal of this test, we disable the compression to get stable numbers. This should avoid wasting more time on this kind of changes in the future.
Mon, 11 Mar 2024 11:09:29 +0100 test-general-delta: actually test optimize-delta-parent-choice=no stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 11 Mar 2024 11:09:29 +0100] rev 51500
test-general-delta: actually test optimize-delta-parent-choice=no Since the configuration was not explicit, the case stopped testing what it intended to test when the default value changed.
Mon, 11 Mar 2024 13:09:01 +0100 test-chg: stabilize the log checking stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 11 Mar 2024 13:09:01 +0100] rev 51499
test-chg: stabilize the log checking The "worker process exited" line have been making the CI flaky for a long time. Lets sort this out.
Mon, 11 Mar 2024 12:03:40 +0100 tests: fix test-patchbomb-tls.t instability stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 11 Mar 2024 12:03:40 +0100] rev 51498
tests: fix test-patchbomb-tls.t instability The flakiness on chg is caused by a client that exit faster than the server output log. So actively wait for the server to issue the expected output (with a small timeout)
Mon, 11 Mar 2024 16:05:28 +0100 test-lock: use synchronisation file instead of sleep stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 11 Mar 2024 16:05:28 +0100] rev 51497
test-lock: use synchronisation file instead of sleep This will prevent the test to be flaky on load.
Sun, 10 Mar 2024 03:29:12 +0100 branchcache: use update_disk to refresh 'served' and 'served.hidden'
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 10 Mar 2024 03:29:12 +0100] rev 51496
branchcache: use update_disk to refresh 'served' and 'served.hidden' The `update_disk` method is dedicated to this kind of usecase. Now that the writting patterns are more consistent, we can use it to warm these two important cache. I am dropping the first comment about "refreshing all the others" because it is false. If a branchmap already exist for "served", none of the subset will be updated.
Sun, 10 Mar 2024 03:25:04 +0100 branchcache: explictly update disk state only if no transaction exist
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 10 Mar 2024 03:25:04 +0100] rev 51495
branchcache: explictly update disk state only if no transaction exist If a transaction exist the `write_dirty` call will eventually be done and the state will be synched on disk. It is better to no interfer with that.
Sun, 10 Mar 2024 03:32:50 +0100 branchcache: do not use `__getitem__` in updatecache
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 10 Mar 2024 03:32:50 +0100] rev 51494
branchcache: do not use `__getitem__` in updatecache The `update_disk` method uses `updatecache` and the point of `update_disk` is to be able to do alternative processing to the one we do in `__getitem__`. So we calling `__getitem__` in `updatecache` defeat this purpose. Instead we do the equivalent explicitly to preserve the spirit of `update_disk` (that we will actually put to use soon, I promise)
Sun, 10 Mar 2024 05:10:00 +0100 branchcache: explicitly track inheritence "state"
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 10 Mar 2024 05:10:00 +0100] rev 51493
branchcache: explicitly track inheritence "state" We move from a binary "dirty" flag to a three value "state": "clean", "inherited", "dirty". The "inherited" means that the branch cache is not only "clean", but it is a duplicate of its parent filter. If a branch cache is "inherited", we can non only skip writing its value on disk, but it is a good idea to delete any stale value on disk, as those will just waste time (and possibly induce bug) in the future. We only do this in the update related to transaction or explicit cache update (e.g `hg debugupdatecache`). Deleting the file when we simply detected a stall cache during a read only operation seems more dangerous. We rename `copy` to `inherit_for` to clarify we associate a stronger semantic to the operation.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 tip