"hg push" hangs for one minute (exactly one minute)

[Ernie Rael]

On 4/29/22 9:55 AM, Anton Shestakov wrote:
> чт, 28 апр. 2022 г. в 23:12, Ernie Rael <err at raelity.com>:
>> On 4/28/22 12:46 PM, Anton Shestakov wrote:
>>> Looks like either another process is holding a lock on caches or the
>>> FS doesn't support locking mechanisms that sqlite3 needs.
>>>
>>> If you want to dig further into this, check around these files:
>>> .hg/cache/evoext_stablerange_v2.sqlite and
>>> .hg/cache/evoext_obshashrange_v2.sqlite
>>>
>> check around these? Not with an editor I think...
>
> I can say that if you find a way to make the evolve caches work on
> SMB, it's worth sending a patch (or sharing the solution here) so it
> can be applied to evolve. These and some other caches in evolve are
> known to be a bit rough around the edges (although it is somewhat
> surprising to see a well-known DB solution have this locking issue),
> and it's planned to do an overhaul of them at some point. But if
> there's a patch to fix this bug, it's going to be put in the earliest
> possible release.
>
Here's an update for the list on this problem from a bug report.

https://bz.mercurial-scm.org/show_bug.cgi?id=6687

Considering this bug affects only pushing to an SMB share or another file
system that doesn't implement the locking mechanism that sqlite wants by
default, and that these caches will be redone at some point (both in 
data that
they store and in the method of storage - sqlite won't be used), right 
now the
best way to deal with this issue is to work around it. You can disable these
caches for the repo that sits on SMB by putting this config in its .hg/hgrc:

[experimental] evolution.obsdiscovery = no

This will disable obsmarker discovery and basically exchange all 
obsmarkers on
push/pull, so the relevant caches won't be used. There's `hg help -e evolve`
with a bit more detail.