Mon, 04 Mar 2024 04:13:33 +0100 config: document the storage and format sections stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 04 Mar 2024 04:13:33 +0100] rev 51446
config: document the storage and format sections This should help people to put configuration in the right section.
Mon, 26 Feb 2024 12:59:57 +0100 rust-index: drop offset_override
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 26 Feb 2024 12:59:57 +0100] rev 51445
rust-index: drop offset_override The inline `offsets` value diverge from the one on disk for added value, so the offset_override tricks is not going to work well once we start having the full revlog logic in Rust. We remove it beforehand and align the Rust logic to the Python one (adjusting the segment offset at read time for inline revlog).
Mon, 26 Feb 2024 13:41:02 +0100 rust-index: stop calling `with_offset` in the tests
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 26 Feb 2024 13:41:02 +0100] rev 51444
rust-index: stop calling `with_offset` in the tests We are not adding any data, so why are we setting any offset?
Fri, 23 Feb 2024 15:57:50 +0100 branching: merge stable into default
Raphaël Gomès <rgomes@octobus.net> [Fri, 23 Feb 2024 15:57:50 +0100] rev 51443
branching: merge stable into default
Fri, 23 Feb 2024 15:55:53 +0100 Added signature for changeset d1d48d18db37 stable
Raphaël Gomès <rgomes@octobus.net> [Fri, 23 Feb 2024 15:55:53 +0100] rev 51442
Added signature for changeset d1d48d18db37
Fri, 23 Feb 2024 15:55:49 +0100 Added tag 6.7rc0 for changeset d1d48d18db37 stable
Raphaël Gomès <rgomes@octobus.net> [Fri, 23 Feb 2024 15:55:49 +0100] rev 51441
Added tag 6.7rc0 for changeset d1d48d18db37
Fri, 23 Feb 2024 15:18:29 +0100 relnotes: add 6.7rc0 stable 6.7rc0
Raphaël Gomès <rgomes@octobus.net> [Fri, 23 Feb 2024 15:18:29 +0100] rev 51440
relnotes: add 6.7rc0
Fri, 23 Feb 2024 15:18:17 +0100 relnotes: remove outdated message from `next` stable
Raphaël Gomès <rgomes@octobus.net> [Fri, 23 Feb 2024 15:18:17 +0100] rev 51439
relnotes: remove outdated message from `next`
Fri, 23 Feb 2024 15:10:44 +0100 branching: merge default into stable for 6.7rc0 stable
Raphaël Gomès <rgomes@octobus.net> [Fri, 23 Feb 2024 15:10:44 +0100] rev 51438
branching: merge default into stable for 6.7rc0
Fri, 23 Feb 2024 15:09:18 +0100 branching: merge stable into default
Raphaël Gomès <rgomes@octobus.net> [Fri, 23 Feb 2024 15:09:18 +0100] rev 51437
branching: merge stable into default
Fri, 23 Feb 2024 14:07:33 +0100 perf: add a --as-push option to perf::unbundle
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 23 Feb 2024 14:07:33 +0100] rev 51436
perf: add a --as-push option to perf::unbundle This turned out to make a quite significant difference.
Fri, 23 Feb 2024 06:25:09 +0100 chainsaw-update: exit early if one of the intermediate command fails
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 23 Feb 2024 06:25:09 +0100] rev 51435
chainsaw-update: exit early if one of the intermediate command fails That will prevent the user to be presented with a start that pretend to be consistent with the request, but is not.
Fri, 23 Feb 2024 03:32:35 +0100 chainsaw-update: lock the repository for the duration of the operation
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 23 Feb 2024 03:32:35 +0100] rev 51434
chainsaw-update: lock the repository for the duration of the operation This should prevent and catch some misusage where something else try to touch the repository.
Fri, 23 Feb 2024 11:41:55 +0100 chainsaw-update: taking care of initial cloning
Georges Racinet <georges.racinet@octobus.net> [Fri, 23 Feb 2024 11:41:55 +0100] rev 51433
chainsaw-update: taking care of initial cloning Perhaps we should go just a bit lower level than this `instance()`, since the main added value in our use-case is full path resolution, that we need to do anyway for the rmtree cleanup.
Fri, 23 Feb 2024 11:30:58 +0100 chainsaw-update: use a graph with branching in graph
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 23 Feb 2024 11:30:58 +0100] rev 51432
chainsaw-update: use a graph with branching in graph This will be relevant for the next improvement of `chainsaw-update`.
Wed, 17 Jan 2024 14:39:06 +0100 chainsaw-update: log actual locks breaking
Georges Racinet <georges.racinet@octobus.net> [Wed, 17 Jan 2024 14:39:06 +0100] rev 51431
chainsaw-update: log actual locks breaking Previously, the command would simply state that it was about to break locks, not if there was actually some to break. This version is race-free. It would be also possible to display the content of the lock before hand (not race-free but informative in almost all cases).
Wed, 17 Jan 2024 14:26:58 +0100 vfs: have tryunlink tell what it did
Georges Racinet <georges.racinet@octobus.net> [Wed, 17 Jan 2024 14:26:58 +0100] rev 51430
vfs: have tryunlink tell what it did It is useful in certain circumstances to know whether vfs.tryunlink() actually removed something or not, be it for logging purposes.
Sat, 26 Nov 2022 12:23:56 +0100 chainsaw: new extension for dangerous operations
Georges Racinet <georges.racinet@octobus.net> [Sat, 26 Nov 2022 12:23:56 +0100] rev 51429
chainsaw: new extension for dangerous operations The first provided command is `chainsaw-update`, whose one and single job is to make sure that it will pull, update and purge the target repository, no matter what may be in the way (locks, notably), see docstring for rationale.
Fri, 23 Feb 2024 03:45:07 +0100 rust: disable the RustIndex without persistent nodemap
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 23 Feb 2024 03:45:07 +0100] rev 51428
rust: disable the RustIndex without persistent nodemap See rational inline.
Fri, 23 Feb 2024 03:44:56 +0100 rust: stop claiming the C index is compatible with the rust code
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 23 Feb 2024 03:44:56 +0100] rev 51427
rust: stop claiming the C index is compatible with the rust code This is no longer the case since the introduction of the pure Rust Index, and was probably not the case since the MixedIndex itself. So we fix the dedicated attribute value.
Thu, 22 Feb 2024 15:11:26 +0100 rust-index: remove one collect when converting back
Raphaël Gomès <rgomes@octobus.net> [Thu, 22 Feb 2024 15:11:26 +0100] rev 51426
rust-index: remove one collect when converting back Turns out this is slightly faster. Sending the results back to Python is still the most costly (like 75% of the time) of the whole method, but it's about as fast as it can be now. hg perf::phases on mozilla-try-2023-03-22 before: 0.267114 after: 0.247101
Thu, 22 Feb 2024 15:06:16 +0100 rust-index: improve phase computation speed
Raphaël Gomès <rgomes@octobus.net> [Thu, 22 Feb 2024 15:06:16 +0100] rev 51425
rust-index: improve phase computation speed While less memory efficient, using an array is *much* faster than using a HashMap, especially with the default hasher. It even makes the code simpler, so I'm not really sure what I was thinking in the first place, maybe it's more obvious now. This fix a significant performance regression when using the rust version of the code. (however, the C code still outperform rust on this operation) hg perf::phases on mozilla-try-2023-03-22 - 6.6.3: 0.451239 seconds - before: 0.982495 seconds - after: 0.265347 seconds - C code: 0.183241 second
Fri, 23 Feb 2024 06:37:25 +0100 phases: directly update the phase sets in advanceboundary
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 23 Feb 2024 06:37:25 +0100] rev 51424
phases: directly update the phase sets in advanceboundary This is similar to what we do in retractboundary. There is no need to invalidate the cache if we have everything at hand to update it.
Fri, 23 Feb 2024 05:25:35 +0100 phases: large rework of advance boundary
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 23 Feb 2024 05:25:35 +0100] rev 51423
phases: large rework of advance boundary In a similar spirit as the rework of retractboundary, the new algorithm is doing an amount of work in the order of magnitude of the amount of changeset that changes phases. (except to find new roots in impacted higher phases if any may exists). This result in a very significant speedup for repository with many old draft like mozilla try. runtime of perf:unbundle for a bundle constaining a single changeset (C code): before 6.7 phase work: 14.497 seconds before this change: 6.311 seconds (-55%) with this change: 2.240 seconds (-85%) Combined with the other patches that fixes the phases computation in the Rust index, the rust code with a persistent nodemap get back to quite interresting performances with 2.026 seconds for the same operation, about 10% faster than the C code.
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -24 +24 +50 +100 +300 tip