Maybe locking is a bzr thing....

[Aaron Bentley]

-----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-----