On Thu, 13 Oct 2016 17:28:02 +0200, Mads Kiilerich wrote:
> On 10/13/2016 05:07 PM, Pierre-Yves David wrote:
> > On 10/13/2016 03:21 PM, Mads Kiilerich wrote:
> >> On 10/13/2016 01:53 PM, Pierre-Yves David wrote:
> >>> # HG changeset patch
> >>> # User Pierre-Yves David <pierre-yves.da...@ens-lyon.org>
> >>> # Date 1476359131 -7200
> >>> # Thu Oct 13 13:45:31 2016 +0200
> >>> # Node ID 88cc944830d0c1895e527d6ca13687f1d5e1c785
> >>> # Parent 747e546c561fbf34d07cd30013eaf42b0190bb3b
> >>> eol: do not wait on lack when writing cache
> >>> The cache writing process is properly catching and handling the case
> >>> where the
> >>> lock is unavailable. However, it fails to specify the lock can failed
> >>> to be
> >>> acquired when requesting it. This is now fixed.
> >> Hmm.
> >> *If* the user has write access to the repo and *could* lock the repo,
> >> then it seems reasonable that it waits for the lock and does the right
> >> thing. It would be unfortunate to bail out early and happily continue to
> >> expose the less optimal state that read only users might have to deal
> >> with.
> > The change introduced by this changeset make the cache in line with
> > how most of other cache works in Mercurial.
> A part of the problem here might be that it is unclear to me what
> happens with wait=False. I don't remember the details: will it continue
> without locking or will it raise? It would be nice to get that clarified
> in the localrepo docstrings.
LockHeld would be raised. So we'll need to catch LockError if wait=False.
Mercurial-devel mailing list