[PATCH 1 of 2] eol: do not wait on lack when writing cache

[Pierre-Yves David]

On 10/13/2016 05:34 PM, Yuya Nishihara wrote:
> 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.david at 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.

And we actually only catch LockUnavailable, lets drop patch 1 for now 
(patch 2 is still valid)

-- 
Pierre-Yves David