Maybe locking is a bzr thing....
Aaron Bentley
aaron.bentley at utoronto.ca
Tue Oct 16 16:53:50 BST 2007
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bruce Korb wrote:
>>> ?? 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)
>
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?
You can put the branch on the NFS filesystem, and put a lightweight
checkout on your private fs. OS locking is only used for working trees,
not for branches or repositories.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHFN6O0F+nu1YWqI0RAjvSAJ4id6lHXKftGH/U8qP65maPg4QdhgCdEI+K
RlR+uceHRXVr/C6Pe5BdY0Q=
=6tp4
-----END PGP SIGNATURE-----
More information about the bazaar
mailing list