[PATCH 4 of 4 stable] PROOF OF CONCEPT: introduce lock validation

Idan Kamara idankk86 at gmail.com
Sat May 12 16:05:10 CDT 2012


On Sat, May 12, 2012 at 9:39 PM, Mads Kiilerich <mads at kiilerich.com> wrote:

> Mads Kiilerich wrote, On 05/12/2012 08:37 PM:
>
>  # HG changeset patch
>> # User Mads Kiilerich<mads at kiilerich.com>
>> # Date 1326326392 -3600
>> # Node ID 715dc5d131f5d690b32925a50a80de**d2bb4b8609
>> # Parent  4a112c51f224358f5c269b06d6ee82**f43b6c9133
>> PROOF OF CONCEPT: introduce lock validation
>>
>> Instrumenting critical places with these checks can help verifying
>> compliance
>> with the locking strategy described on
>> http://mercurial.selenic.com/**wiki/LockingDesign<http://mercurial.selenic.com/wiki/LockingDesign>
>> .
>>
>> Occasionally running the test suite with this patch might catch some
>> locking
>> errors, but the checking as it is is probably too intrusive for inclusion
>> in
>> core Mercurial.
>>
>
> Idan, you mentioned you had a patch for something similar ... something
> that apparently caught a different set of problems?


It caught the same problems but it seems like I missed a few
in hgext/.

I did something similar to your check(w)lock methods,
only it was a decorator and it was a no-op when run outside the
test suite. The problem was making it generic since it needs
access to a localrepo object, or at least a repo path. Maybe
we can do a similar trick like filecache, storecache, etc.

Can't say I like those asserts though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120513/91ce4200/attachment.html>


More information about the Mercurial-devel mailing list