eol bug (was RE: hg in/pull on afs)

Matt Mackall mpm at selenic.com
Fri Dec 17 14:21:10 CST 2010


On Fri, 2010-12-17 at 14:30 -0500, Kolominsky, Alex wrote:
[...]
>   File "/ms/dist/fsf/PROJ/mercurial/1.7.1/.exec/@sys/lib/python2.6/site-packages/mercurial/hg.py", line 420, in _incoming
>     other = repository(remoteui(repo, opts), source)
>   File "/ms/dist/fsf/PROJ/mercurial/1.7.1/.exec/@sys/lib/python2.6/site-packages/mercurial/hg.py", line 101, in repository
>     hook(ui, repo)
>   File "/ms/dist/fsf/PROJ/mercurial/1.7.1/.exec/@sys/lib/python2.6/site-packages/hgext/eol.py", line 266, in reposetup
>     repo._hgcleardirstate()
>   File "/ms/dist/fsf/PROJ/mercurial/1.7.1/.exec/@sys/lib/python2.6/site-packages/hgext/eol.py", line 239, in _hgcleardirstate
>     wlock = self.wlock()
[...]
> LockUnavailable: [Errno 13] Permission denied: '/afs/.global/ln.w/user/u/username/path/.hg/wlock'
> abort: could not lock working directory of /afs/user/u/username/path/: Permission denied

Ahh, yes, that should have been obvious.

There's no reason we should be doing whatever mysterious thing it is
that _hgcleardirstate() is doing unless we actually look at the
dirstate, which never happens here. But we're doing it unconditionally
if eol is enabled.

Martin?

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial mailing list