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