Wed, 06 Mar 2024 12:07:31 +0100 branchcache: show the cache file content in test-branches-obsoletes.t
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Mar 2024 12:07:31 +0100] rev 51528
branchcache: show the cache file content in test-branches-obsoletes.t This help to track the changes in format between v2 and v3.
Wed, 06 Mar 2024 02:20:53 +0100 branchcache: rework the `filteredhash` logic to be more generic
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Mar 2024 02:20:53 +0100] rev 51527
branchcache: rework the `filteredhash` logic to be more generic We now have a more flexible `key_hashes` tuple. We duplicated various logic in the V2 and V3 version of the cache as the goal is to start changing the logic for V3 in the next few changesets.
Wed, 06 Mar 2024 01:53:52 +0100 filteredhash: rename the filteredhash function
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Mar 2024 01:53:52 +0100] rev 51526
filteredhash: rename the filteredhash function The new name is less ambiguous, as we are about to introduce an alternative function it seems like a good idea to have clearer name to distinct the two.
Wed, 06 Mar 2024 01:43:51 +0100 filteredhash: split the computation of revision sets
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Mar 2024 01:43:51 +0100] rev 51525
filteredhash: split the computation of revision sets The branch2's filteredhash combines the filtered revisions and the obsolete ones, this will creates issue for implicit reference to heads we want to introduce for the v3 of the branch cache format. So we isolate this logic for alternative use.
Tue, 05 Mar 2024 15:21:18 +0100 filteredhash: move the hashing in its own function
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 05 Mar 2024 15:21:18 +0100] rev 51524
filteredhash: move the hashing in its own function This will help us to reuse this logic in variants of the hashes used for branch cache validation.
Sun, 25 Feb 2024 23:31:50 +0100 branchcache: cleanup the final key generation after update
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 25 Feb 2024 23:31:50 +0100] rev 51523
branchcache: cleanup the final key generation after update A lot of duplicated work seemed to be done, as we already update the tiprev and tipnode when needed right before. So we simplify that part to focus on the filtered hash. See inline comment for details.
Wed, 28 Feb 2024 12:56:08 +0100 branchcache: add more test for the logic around obsolescence and branch heads
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 28 Feb 2024 12:56:08 +0100] rev 51522
branchcache: add more test for the logic around obsolescence and branch heads While working on branch-cache-v3, we noticed some ambiguity in the filtered+obsolete hash. However this was only caught by a rebase test by chance. It seems important to explicitly tests these cases.
Mon, 26 Feb 2024 15:44:44 +0100 branchcache-v3: use more explicit header line
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 26 Feb 2024 15:44:44 +0100] rev 51521
branchcache-v3: use more explicit header line The key-value approach is clearer and gives more rooms to have the format evolve in a clear way. It also provides extension (like topic) simpler way to extend the validation scheme. This is just a small evolution, the V3 format is still a work in progress.
Mon, 26 Feb 2024 14:20:36 +0100 branchcache-v3: introduce a v3 format
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 26 Feb 2024 14:20:36 +0100] rev 51520
branchcache-v3: introduce a v3 format For now the format is the very same, however we will start changing it in future changesets.
Tue, 27 Feb 2024 14:04:29 +0100 branchcache: use an explicit class for the v2 version
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 27 Feb 2024 14:04:29 +0100] rev 51519
branchcache: use an explicit class for the v2 version This prepare the introduction of an experimental v3 format version. In the process, we move the description of the format in that new class.
Tue, 27 Feb 2024 15:33:21 +0100 branchcache: add some blank line in a test
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 27 Feb 2024 15:33:21 +0100] rev 51518
branchcache: add some blank line in a test This helps each section to stand out.
Mon, 25 Mar 2024 02:09:15 +0100 phases: update the phase set as we go during retract boundary stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 25 Mar 2024 02:09:15 +0100] rev 51517
phases: update the phase set as we go during retract boundary Apparently iterating over the `changed_revs` dictionary is very expensive. On mozilla-try-2019-02-18, a perf::unbundle call with a 10 000 changesets bundle gives give use the following timing. e57d4b868a3e: 4.6 seconds ac1c75188440: 102.5 seconds prev-changeset: 30.0 seconds this-changeset: 4.6 seconds So, the performance regression is gone. Once again: thanks to marvelous Python!
Mon, 25 Mar 2024 01:50:31 +0100 phases: avoid a potentially costly dictionary interation in some case stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 25 Mar 2024 01:50:31 +0100] rev 51516
phases: avoid a potentially costly dictionary interation in some case If we retract for the draft phase, there is not non-public item to be retracted and we can skip this part. This part is was apparently super costly thanks to Python. On mozilla-try-2019-02-18, a perf::unbundle call with a 10 000 changesets bundle gives give use the following timing. e57d4b868a3e: 4.6 seconds ac1c75188440: 102.5 seconds this-changeset: 30.0 seconds So we recovered about ⅔ of the regression, the next changeset will give us the rest back.
Thu, 21 Mar 2024 12:26:46 +0100 branching: merge stable into default
Raphaël Gomès <rgomes@octobus.net> [Thu, 21 Mar 2024 12:26:46 +0100] rev 51515
branching: merge stable into default
Thu, 21 Mar 2024 12:24:42 +0100 Added signature for changeset 2e6fde2ed01e stable
Raphaël Gomès <rgomes@octobus.net> [Thu, 21 Mar 2024 12:24:42 +0100] rev 51514
Added signature for changeset 2e6fde2ed01e
Thu, 21 Mar 2024 12:24:36 +0100 Added tag 6.7.1 for changeset 2e6fde2ed01e stable
Raphaël Gomès <rgomes@octobus.net> [Thu, 21 Mar 2024 12:24:36 +0100] rev 51513
Added tag 6.7.1 for changeset 2e6fde2ed01e
Thu, 21 Mar 2024 12:23:25 +0100 relnotes: add 6.7.1 stable 6.7.1
Raphaël Gomès <rgomes@octobus.net> [Thu, 21 Mar 2024 12:23:25 +0100] rev 51512
relnotes: add 6.7.1
Sat, 16 Mar 2024 21:02:19 -0300 subrepo: fix normalizing paths with scheme stable
Felipe Resende <felipe@fcresende.dev.br> [Sat, 16 Mar 2024 21:02:19 -0300] rev 51511
subrepo: fix normalizing paths with scheme After revision 0afe96e374a7, subrepo paths were normalized using posixpath.normpath and that resulted in ssh paths being wrongly converted from ssh://host/path to ssh:/host/path This fix applies the same logic used in urlutil.url to split the path scheme from the rest and only use posixpath.normpath to the string after scheme://
Sat, 16 Mar 2024 18:37:07 -0300 sshpeer: fix path when handling invalid url exception stable
Felipe Resende <felipe@fcresende.dev.br> [Sat, 16 Mar 2024 18:37:07 -0300] rev 51510
sshpeer: fix path when handling invalid url exception In 73ed1d13c0bf the code was refactored but the error handling seems to have been missed (or maybe the object shoud have implemented __bytes__)
Mon, 18 Mar 2024 11:25:21 +0100 delta-search: fix crash caused by unbound variable stable
Raphaël Gomès <rgomes@octobus.net> [Mon, 18 Mar 2024 11:25:21 +0100] rev 51509
delta-search: fix crash caused by unbound variable This code path was apparently not tested. This fixes a crash when cloning the Tryton repo.
Fri, 15 Mar 2024 10:52:51 +0100 branching: merge stable into default
Raphaël Gomès <rgomes@octobus.net> [Fri, 15 Mar 2024 10:52:51 +0100] rev 51508
branching: merge stable into default
Fri, 15 Mar 2024 10:49:44 +0100 Added signature for changeset c9ceb4f60256 stable
Raphaël Gomès <rgomes@octobus.net> [Fri, 15 Mar 2024 10:49:44 +0100] rev 51507
Added signature for changeset c9ceb4f60256
Fri, 15 Mar 2024 10:49:40 +0100 Added tag 6.7 for changeset c9ceb4f60256 stable
Raphaël Gomès <rgomes@octobus.net> [Fri, 15 Mar 2024 10:49:40 +0100] rev 51506
Added tag 6.7 for changeset c9ceb4f60256
Fri, 15 Mar 2024 01:31:57 +0100 phases: avoid N² behavior in `advanceboundary` stable 6.7
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 15 Mar 2024 01:31:57 +0100] rev 51505
phases: avoid N² behavior in `advanceboundary` We allowed duplicated entries in the deque, which each entry could potentially insert all its ancestors. So advancing boundary for the full repository would mean each revision would walk all its ancestors, resulting in O(N²) iteration. For repository of any decent size, N² is quickly insane. We introduce a simple set to avoid this and get back to reasonable performance.
Thu, 14 Mar 2024 16:25:46 +0100 relnotes: add 6.7 stable
Raphaël Gomès <rgomes@octobus.net> [Thu, 14 Mar 2024 16:25:46 +0100] rev 51504
relnotes: add 6.7
Thu, 14 Mar 2024 11:24:52 +0100 admin-commands: move the chainsaw extension to the admin commands module stable
Raphaël Gomès <rgomes@octobus.net> [Thu, 14 Mar 2024 11:24:52 +0100] rev 51503
admin-commands: move the chainsaw extension to the admin commands module Activating an extension is always a little bit of a chore and the long name, options and "chainsaw" bits are deterrent enough. This also allows us to help the discoverability for people looking for repo "administration" tools, with the widest semantic of "administration".
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.
Sun, 10 Mar 2024 04:53:17 +0100 branchcache: stop writing more branchcache file on disk than needed
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 10 Mar 2024 04:53:17 +0100] rev 51492
branchcache: stop writing more branchcache file on disk than needed Before this change, we were unconditionally writing a branchmap file for the filter level passed to `update_disk`. This is actually counter productive if no update were needed for this filter level. In many case, the branch cache for a filter level is identical to its parent "subset" and it is better to simply keep the subset update and reuse it every time instead of having to do identical work for similar subset. So we change the `update_disk` method to only write a file when that filter level differ from its parent. This removes many cases where identical files were written, requiring multiple boring update in the test suite. The only notable changes is the change to `test-strip-branch-cache.t`, this case was checking a scenario that no longer reproduce the bug as writing less branchmap file result in less stalled cache on disk. Strictly speaking, we could create a more convoluted scenario that create a similar issue. However the next changeset would also cover that scenario so we directly updated that test case to a "no longer buggy" state.
Fri, 08 Mar 2024 16:49:06 +0100 branchcache: do not copy the `_dirty` flag
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 08 Mar 2024 16:49:06 +0100] rev 51491
branchcache: do not copy the `_dirty` flag If the inherited branch cache is dirty, it will be written on disk, and the super-set did not need to modify it, the on disk value for the subset will be re-useable as is. So the super set does not needs to write the very same content itself.
Fri, 08 Mar 2024 16:52:08 +0100 branchcache: explicitly assert that copy is always about inheritance
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 08 Mar 2024 16:52:08 +0100] rev 51490
branchcache: explicitly assert that copy is always about inheritance This would catch cases where copy is used for something else if any existed.
Sat, 09 Mar 2024 02:07:15 +0100 branchcache: stop using `copy(…)` in `replace(…)`
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 09 Mar 2024 02:07:15 +0100] rev 51489
branchcache: stop using `copy(…)` in `replace(…)` The `copy` method is mostly used for a filter level to inherit the branchmap from a subset. So we stop using (abusing) it in "replace" to ensure `copy` is used only for inheritance purposes. Since `replace` is a method of the BranchMapCache, it seems fine to do lower level operation there.
Fri, 08 Mar 2024 16:47:32 +0100 branchcache: change the _delayed flag to an explicit `_dirty` flag
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 08 Mar 2024 16:47:32 +0100] rev 51488
branchcache: change the _delayed flag to an explicit `_dirty` flag This is more consistent with the logic we use for other object and it open the way to a clearer management of the cache state. Now, cache are created clean, cache update mark them dirty, writing them on disk mark them clean again.
Fri, 08 Mar 2024 15:50:15 +0100 branchcache: write branchmap in subset inheritance order
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 08 Mar 2024 15:50:15 +0100] rev 51487
branchcache: write branchmap in subset inheritance order This way, we can guarantee a valid subset has been written before touching the branchmap of another filter. This is especially useful as we are bout to start deleting outdated branchmap file.
Fri, 08 Mar 2024 15:06:54 +0100 branchcache: do not accept "empty update"
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 08 Mar 2024 15:06:54 +0100] rev 51486
branchcache: do not accept "empty update" This currently does not happens and it will be simpler that is remains that way. If all update do something, we will be able to simply declare, in a later changesets, that all update to result in a dirty branchcache.
Thu, 07 Mar 2024 11:04:34 +0100 branchcache: avoid created a `None` filter repoview when writing
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 07 Mar 2024 11:04:34 +0100] rev 51485
branchcache: avoid created a `None` filter repoview when writing The repoview class is not intended to be used for unfiltered repository.
Wed, 28 Feb 2024 22:49:55 +0100 stream-clone-tests: stop filtering non existent warning
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 28 Feb 2024 22:49:55 +0100] rev 51484
stream-clone-tests: stop filtering non existent warning This filtering was introduced in 74c004a515bc, however there is already no warning in that changeset. So I guess the warnings existed when we the patch was created but the problem was solved in another changeset that 74c004a515bc, rebased on.
Wed, 28 Feb 2024 22:46:12 +0100 stream-clone-test: simplify case testing obsolescence
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 28 Feb 2024 22:46:12 +0100] rev 51483
stream-clone-test: simplify case testing obsolescence There is only two important things in this test: - the number of file we send, to show we picked the obsstore. - the resulting state, to show we did alter things in the process. The rest are of the number are very fragile and consume a lot of time for little value when adjusting formats, caches, and protocol.
Wed, 28 Feb 2024 22:43:07 +0100 stream-clone-test: simplify the case testing phases
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 28 Feb 2024 22:43:07 +0100] rev 51482
stream-clone-test: simplify the case testing phases There is only two important things in this test: - the number of file we send, to show we picked the phase roots. - the resulting phases, to show we did not modified them. The rest are of the number are very fragile and consume a lot of time for little value when adjusting formats, caches, and protocol.
Wed, 28 Feb 2024 22:39:10 +0100 stream-clone-test: simplify bookmark clone
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 28 Feb 2024 22:39:10 +0100] rev 51481
stream-clone-test: simplify bookmark clone The important things to test here is the number of file included (to catch that the bookmark file was sent). So we keep that part non glob'ed but glob the rest. The glob'ed numbers are very fragile and consume a lot of time for little value when adjusting formats, caches, and protocol.
(0) -30000 -10000 -3000 -1000 -300 -100 -48 +48 +100 +300 tip