Maybe locking is a bzr thing....

Bruce Korb bruce.korb at gmail.com
Tue Oct 16 16:42:12 BST 2007


> > ??  That has been integrated into UNIX-y systems since forever (OK, since
> > a couple of decades ago).
>
> Well, I'm glad to know that locking problems it's not only the problem
> for poor windows users, but for powerful unix masters too, who have this
>   "integrated into UNIX-y systems since forever".

Yes, it is true.  Sun did not carefully consider concurrent access
with the initial NFS
implementation.  They wrote it just to address their needs for
networked access to
a file system.  Windows inherited the problem.  One rare problem that Windoze
didn't cause.  ;-)  So, NFSv4 addressed this and other problems,
but still isn't in widespread use.  Anyway, back to endless bzr
locking problems:

$ bzr init --knit
bzr: ERROR: Already a branch: ..
$ bzr update

bzr: ERROR: Could not acquire lock [Errno 37] No locks available
/usr/lib/python2.4/site-packages/bzrlib/lock.py:79: UserWarning: lock
on <open file u'/share/st/devbk/simple-cdd-0.3.5/.bzr/checkout/dirstate',
mode 'rb+' at 0xb7cb36e0> not released
  warn("lock on %r not released" % self.f)

So maybe shared access on an NFS mount without locking support is not possible
with bzr.  That's fine.  I just want single user access anyway.
However, right now
it seems impenetrably difficult.  I need up-to-date "simple-cdd" which means  I
need bzr.  The repository needs to be visible across our LAN, which means
using a file system hosted on a "secured" system.  I don't have admin
privs there.
Our secured systems are adminisered by people who basically speak Windows.
Now, what?  :(  I guess I can ``bzr clone'' to a private fs and then
copy the hiererchy
over to a net visible fs.  Seems like less trouble than any thing
else.  Thanks - Bruce



More information about the bazaar mailing list