Thread (47 messages) flat view 47 messages, 5 authors, 19d ago

Re: [PATCH 1/4] odb: decouple source path comparisons from `the_repository`

From: Patrick Steinhardt <hidden>
Date: 2026-08-12 05:39:19

On Tue, Aug 11, 2026 at 05:04:58PM -0500, Justin Tobler wrote:
On 26/08/10 03:33PM, Patrick Steinhardt wrote:
quoted
When registering alternates we deduplicate object database sources by
their path so that the same source won't be added twice. Ever since
cf2dc1c238 (speed up alt_odb_usable() with many alternates, 2021-07-07)
this duplicate check is backed by a map keyed by the source's path,
using `fspathhash()` and `fspatheq()` as hash and equality functions,
respectively.

These functions are problematic in this context for two reasons:

  - They implicitly depend on `the_repository` instead of the
    repository that owns the object database.

  - They derive case-sensitivity from `repo_ignore_case()`, which
    returns a default value in case the repository's configuration has
    not been parsed yet. Object database sources may be registered
    before that is the case, so the answer may flip depending on when a
    source gets registered.
Are alternates currently always registered after repository
configuration has been parsed? Or is this an existing bug?
They are, because of the lazy-loading. So this is not a bug, we merely
have to ensure that we retain this behaviour.
quoted
Overall it's quite debatable whether all of this complexity really is
worth it, or whether we should just linearly search through all sources
to find duplicates. But the mentioned commit cares about cases with
thousands of alternates, and a linear search would of course regress
performance quite a bit. This doesn't really feel like a reasonable case
to care about though, but I don't feel comfortable regressing it anyway.
Ya, my first though here was also whether all of this song and dance is
really needed for alternates. There may be someone out there with tons
of alternates I guess though. Probably good to be on the safe side.
cf2dc1c238 (speed up alt_odb_usable() with many alternates, 2021-07-07)
mentions a repository with 100k alternates in total, but that's an
artificial testing setup. I doubt you can get any kind of reasonable
performance out of such a repository, regardless of whether on not
parsing the alternates is going to be fast.

For now though I didn't want to remove this infra. It feels overblown,
but it's not an unmaintainable mess, either.

Patrick
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help