With HgRepositoryLock introduced recently, cooperation between Java and native
clients is possible. However, native client occasionally fails like:
Traceback (most recent call last):
File "mercurial\dispatch.pyc", line 87, in _runcatch
File "mercurial\dispatch.pyc", line 679, in _dispatch
File "mercurial\dispatch.pyc", line 454, in runcommand
File "mercurial\dispatch.pyc", line 733, in _runcommand
File "mercurial\dispatch.pyc", line 687, in checkargs
File "mercurial\dispatch.pyc", line 676, in <lambda>
File "mercurial\util.pyc", line 385, in check
File "mercurial\commands.pyc", line 167, in add
File "mercurial\cmdutil.pyc", line 1172, in add
File "mercurial\context.pyc", line 814, in add
File "mercurial\localrepo.pyc", line 828, in wlock
File "mercurial\localrepo.pyc", line 790, in _lock
File "mercurial\lock.pyc", line 38, in __init__
File "mercurial\lock.pyc", line 56, in lock
File "mercurial\lock.pyc", line 80, in trylock
File "mercurial\lock.pyc", line 99, in testlock
File "mercurial\util.pyc", line 528, in readlock
File "mercurial\windows.pyc", line 20, in posixfile
IOError: [Errno 2] <...>\hg\test-lock\.hg\wlock: The system cannot find the
file specified
abort: <...>\hg\test-lock\.hg\wlock: The system cannot find the file specified
I believe this is due to programming error in Mercurial, rather than in Hg4J.
There's a gap when lock.py tries to create a lock (1), finds out lock exists
(2) and then it tries to read lock file (3) to find out who holds it. If the
process that holds the lock releases it (removes the file) between (2) and (3),
the attempt to read lock file in (3) expectedly fails.
Perhaps, shall be reported to mercurial list?
Original issue reported on code.google.com by tikhomir...@gmail.com on 13 Aug 2012 at 5:14
Original issue reported on code.google.com by
tikhomir...@gmail.comon 13 Aug 2012 at 5:14