[Commented On] D11817: sparse: lock the store when updating requirements config

[marmoute (Pierre-Yves David)]

marmoute added a comment.


  1. I agree that we should take the `wlock` in addition to the `lock` as we will be running an upgrade.
  2. the best way to get out of your trouble is to make the "new" peer (created after status) aware of the locking. Something like the logic below seems "suitable", Since this only happens in this specific cases, it seems like a bad idea to alter too much of the main `peer` API (we could still have a dedicated method on the repository for that)
  
  (I did not run this code)
  
    diff --git a/mercurial/hg.py b/mercurial/hg.py
    --- a/mercurial/hg.py
    +++ b/mercurial/hg.py
    @@ -873,6 +873,13 @@ def clone(
                 # we need to re-init the repo after manually copying the data
                 # into it
                 destpeer = peer(srcrepo, peeropts, dest)
    +
    +            # make the peer aware that is it already locked
    +            #
    +            # important:
    +            #
    +            #    We still need to release that lock at the end of the function
    +            destpeer.local()._lockref = weakref.ref(destlock)
                 srcrepo.hook(
                     b'outgoing', source=b'clone', node=srcrepo.nodeconstants.nullhex
                 )

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D11817/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D11817

To: aalekseyev, #hg-reviewers, Alphare
Cc: marmoute, mercurial-patches
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercurial-scm.org/pipermail/mercurial-patches/attachments/20211203/512bbea6/attachment.html>