Issue #2537 - permission denied on lock files on Windows - How do I contribute?

[Adrian Buehlmann]

On 2011-01-05 15:57, Lasse Vågsæther Karlsen wrote:
> I have, as I've described before, a .NET project that aims to wrap up
> the Mercurial command line client for .NET programs, so that I can write
> a program that uses Mercurial, for whatever purposes.
> 
> In order to test this library, I have created hundreds of unit and
> integration tests, many (6-700) of which ends up shelling out to call
> hg, and then I verify the results. Many of the tests execute multiple
> commands in sequence as well, for instance I might initialize a new
> repository, then commit a file to it, and then verify that everything is OK.
> 
> This fails with the exact error message shown in case 2537
> (http://mercurial.selenic.com/bts/issue2537), like this:
> 
> Test(s) failed. Mercurial.MercurialExecutionException : abort: could not lock working directory of C:\TeamCity\buildAgent\temp\buildTmp\79e016a4a3f7443b867b87f5cd2aed9a: Permission denied
>    at Mercurial.CommandBase`1.ThrowOnUnsuccessfulExecution(Int32 exitCode, String standardOutput, String standardErrorOutput) in c:\TeamCity\buildAgent\work\5fa6b353cdfc3c5a\Mercurial.Net\CommandBase.cs:line 349
>    at Mercurial.CommandBase`1.After(Int32 exitCode, String standardOutput, String standardErrorOutput) in c:\TeamCity\buildAgent\work\5fa6b353cdfc3c5a\Mercurial.Net\CommandBase.cs:line 254
> 
> The stack trace shows that it is the commit command that fails, and this
> follows the init command immediately. Basically, the lock from the
> initialization command is left around and thus commit fail.
> 
> Since I run so many unit tests, it's actually an exception (not a
> program exception, an english exception, aka "exception to the rule")
> that all the tests succeed. 9 out of 10 times, one or more tests fail
> with that exact problem.
> 
> I also have a nightly bigger integration test that runs all the tests
> using multiple versions of the command line client, at the moment it
> tests them with 1.6.1, 1.6.2, 1.6.3, 1.7.0, 1.7.1, 1.7.2 and 1.7.3, and
> this of course means that the chance of it succeeding without any such
> problems is just 14% of the single execution, which seems to fail all
> the time.
> 
> So I'd like to get it fixed, or help out, in any way I can.
> 
> I have created a simple batch file that creates a new repository,
> changes the same file 1000 times, and for each change, commits it to the
> repository. So far, it has consistently failed at least 5 times every
> time I run it.
> 
> What are my options for contributing here?
> 
> * Contribute the batch file, so that someone who knows Mercurial can try it?
> * Dig into the code and try to come up with a good fix myself?
> 
> In terms of the latter, I'm not a really good Python programmer, but I
> could probably learn enough to come up with something. "kiilerix" on irc
> showed me that in windows.py, in the rename function, there's some code
> to generate a random filename, which could probably be used for this.
> 
> I gather that the fix would have to be in lock.py, in the release
> method: http://selenic.com/repo/hg/file/f3058dd05281/mercurial/lock.py#l121,
> and that line 129 that simply unlinks the file would have to rename it
> first (as per the suggestion in issue 2537.)
> 
> Any advice would be welcome, it's mighty irritating that my build server
> almost always fails to build and test my project.

Did you try my patch series
http://selenic.com/pipermail/mercurial-devel/2011-January/027441.html
?