[Commented On] D9679: sharesafe: introduce functionality to automatically upgrade shares
marmoute (Pierre-Yves David)
phabricator at mercurial-scm.org
Fri Jan 15 09:55:38 UTC 2021
marmoute added a comment.
(I just found out I had unsubmitted comments…)
INLINE COMMENTS
> pulkit wrote in configitems.py:1077-1078
> Sure, that sounds good.
Lets add a comment with the planned final name next to the config declaration then.
> upgrade.py:284-286
> + loading. It may also fails to upgrade if we fails to get a lock. Hence
> + we need to update the caller about new set of repository requirements.
> + Therefore returns the set of new repository requirement.
This part is not very clear. Do you mean we can silently (from the code perspective) fail to upgrade ? And that depending of if this works or not, we use a different set of requirements for the share ?
> upgrade.py:289-290
> + wlock = None
> + try:
> + wlock = lockmod.trylock(ui, hgvfs, b'wlock', 0, 0)
> + store_requirements = localrepo._readrequires(storevfs, False)
What about we use try/else construct to restrict the try block to one actually trying to grab the lock ?
try:
wlock = lockmod.trylock(ui, hgvfs, b'wlock', 0, 0)
except LockError as e:
…
else:
…
finally:
…
REPOSITORY
rHG Mercurial
CHANGES SINCE LAST ACTION
https://phab.mercurial-scm.org/D9679/new/
REVISION DETAIL
https://phab.mercurial-scm.org/D9679
To: pulkit, #hg-reviewers, marmoute, Alphare
Cc: martinvonz, marmoute, mercurial-patches
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-patches/attachments/20210115/f2fbfd07/attachment-0002.html>
More information about the Mercurial-patches
mailing list