Commit hook to find out who is holding a lock?

[Alban Hertroys]

Matt Mackall <mpm at selenic.com> wrote on 27/02/2015 20:52:53:

> 

alban.hertroys at apollovredestein.com
T: 




 	Apollo Vredestein B.V. - P.O. Box 27 - 7500 AA  Enschede - The Netherlands - 
Chamber of Commerce number 34223268 - http://www.apollovredestein.com	 

The information contained in this e-mail is intended solely for the use of the 
individual or entity to whom it is addressed and others authorized to receive 
it. You are hereby notified that any disclosure, copying, distribution or 
action in relation to the contents of this information is strictly prohibited. 
If you are not the intended recipient, please delete this message and any 
attachments and advise the sender by return e-mail. The confidentiality of this 
message is not warranted. Apollo Vredestein B.V. rules out any and every 
liability resulting from this or any other electronic transmission.
 
On Thu, 2015-02-26 at 17:03 +0100, Alban Hertroys wrote:
> > Hi all,
> > 
> > We're having an issue where files in our single shared repository are 
> > being locked by 'something' and we're trying to figure out what is 
causing 
> > this. The lock conflict only seems to happen on commits or updates, 
most 
> > often on commits. Meanwhile the files are being used (read) by a 
server 
> > process (tscom3, part of WebFOCUS) on the machine hosting the 
repository.
> 
> Is there an error message? Nothing in Mercurial does file-level locking.
> 
> However Windows has a notion of file exclusivity by default that it
> inherited from its misguided DOS + LanManager youth. Which means that
> when a poorly-written virus scanner (but I repeat myself) sees something
> touching a file.. it rushes in to check it and thereby locks you out.
> So.. probably a virus scanner.

I think I finally found the culprit. We use the keyword extension to add 
$Revision$ information to our code[*]. I just had one such locking issue, 
and in the physical file the string is still '$Revision$', but in the 
repository it has changed to '$Revision: 0e72bb884edf $'! Is that a 
plausable conclusion?

We use tortoiseHg (3.3 in my case); is it possible that version came with 
an outdated version of the keyword extension?

Cheers,

Alban Hertroys.

*:  Our users use that info to see whether a revision of a report or page 
on our test/acceptation server has already been released to production or 
that release is still pending.