tracopt.versioncontrol.git.tests.git_fs.GitCachedRepositoryTestCase failure on Windows

[Christian Boos]

======================================================================
ERROR: test_sync_too_many_merges (tracopt.versioncontrol.git.tests.git_fs.GitCachedRepositoryTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\projects\trac\tracopt\versioncontrol\git\tests\git_fs.py", line 112, in tearDown
    rmtree(self.repos_path)
  File "C:\projects\trac\trac\tests\compat.py", line 101, in rmtree
    shutil.rmtree(path, onerror=onerror)
  File "C:\Python27\lib\shutil.py", line 247, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "C:\Python27\lib\shutil.py", line 247, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "C:\Python27\lib\shutil.py", line 252, in rmtree
    onerror(os.remove, fullname, sys.exc_info())
  File "C:\projects\trac\trac\tests\compat.py", line 94, in onerror
    function(path)
WindowsError: [Error 5] Access is denied: u'c:\\users\\appveyor\\appdata\\local\\temp\\1\\trac-gitrepos-zkbb4q\\objects\\pack\\pack-a7f586d90bd005eeaba49e459c29777f62fcf408.idx'

The problem happens only on 1.0-stable, not on trunk

Also, only the stock Python 2.7.11 builds (both x86 and x64) show the issue. Of note, the Conda builds (also 2.7.11) don't have it.

(it can happen with any Python variant)

I couldn't reproduce locally, but then I have a much older version of git (1.9.4.msysgit.1 vs. 2.6.3.windows.1 on AppVeyor).

[Christian Boos]

Also, only the stock Python 2.7.11 builds (both x86 and x64) show the issue. Of note, the Conda builds (also 2.7.11) don't have it.

Just got it with ​Python 2.6 (x64), so it doesn't depend on the Python version.

[Jun Omae]

Hmmm, I cannot reproduce with 1.9.5.msysgit.0, 2.6.3.windows.1 and 2.7.0.windows.1.

[Jun Omae]

Reproduced with Windows 10, Python 2.7.11 and 2.6.3.windows.1. I'll investigate it.

[Jun Omae]

Replying to Jun Omae:

Reproduced with Windows 10, Python 2.7.11 and 2.6.3.windows.1. I'll investigate it.

The issue goes away to set PATH=C:\git\mingw64\bin;%PATH% instead of PATH=C:\git\bin;%PATH% (using directly C:\git\mingw64\bin\git.exe). I don't know why….

[Christian Boos]

Replying to Christian Boos:

Also, only the stock Python 2.7.11 builds (both x86 and x64) show the issue. Of note, the Conda builds (also 2.7.11) don't have it.

Just got it with ​Python 2.6 (x64), so it doesn't depend on the Python version.

And also got it for one Conda build, so it's not related.

The failures are not systematic ones, got one green build (​1.0-stable.6), then the next got 2 such errors (​Python27-x64, ​Miniconda-x64).

[Christian Boos]

Replying to Christian Boos:

The problem happens only on 1.0-stable, not on trunk

We also have it on trunk sometimes (​trunk.18), which is reassuring as I couldn't see the difference in the code between 1.0-stable and trunk in relation with that problem.

[Christian Boos]

Recent builds passed. Maybe because there's a new version of git? (git version 2.7.0.windows.1). Let's see if it stays that way.

[Christian Boos]

Replying to Christian Boos:

Recent builds passed. Maybe because there's a new version of git? (git version 2.7.0.windows.1). Let's see if it stays that way.

Hm. No.

External dependencies:
  Git version: git version 2.7.0.windows.1
 
...
ERROR: test_sync_too_many_merges (tracopt.versioncontrol.git.tests.git_fs.GitCachedRepositoryTestCase)
...
WindowsError: [Error 5] Access is denied: u'c:\\users\\appveyor\\appdata\\local\\temp\\1\\trac-gitrepos-8jt6ms\\objects\\pack\\pack-a7f586d90bd005eeaba49e459c29777f62fcf408.idx'

[Christian Boos]

Giving up for now on fully understanding what's happening with this one, but we need a fix so that AppVeyor builds can start to become useful.

Retrying the deletion works (1 retry was always enough in my experiments), as done in r14605 (merged on trunk in r14606).

[Ryan J Ollos]

Also reported in #12450.

[Christian Boos]

Note that this was likely caused by git for windows' issue ​500, which was only fixed for v2.7.0.windows.2.

But it looks like there are still similar issues in later version (#750, #770). Reverting r14606 could tell…