multiple users at the same time on one repo...

[John Arbash Meinel]

T Budiman wrote:
>> Your approach to have everyone use the same branch
>> means that you have a
>> different problem. Waiting on a lock won't help you,
>> because your branch
>> is now out of date if someone commits before you.
>> You have to update
>> locally.
> 
> It's true for bzr commit. But at least for bzr update
> it's make sense to wait on the lock.
> 

'bzr update' only requires a read-lock. And in bzr read-lock is a no-op
that just enables caching. The way we write updates mean that new writes
don't invalidate earlier read data.

> 
>> Sounds like a plain bug. But I'm thinking the
>> problem is permissions.
>> Try running:
>>
>> chown -R .group .bzr/
>> find .bzr -type d -print0 | xargs -0 chmod 2775
>> find .bzr -type f -print0 | xarsg -0 chmod 664
> 
> Oh, yes, I think this setup should work. Our default
> umask is actually 022, but I think I can change it to
> 002. OK, thank you, I'll post to the list if we get
> any more problems with this setup.
> 

...

> I'm not sure I could follow you on this one. Why
> peeking before breaking could cause problems?

Just because when we peak, if we could not read the file, we might
abort, rather than just prompting the user that 'Branch is locked, but
we don't know by whom'.

> 
> Are those pending directories actually usable for
> something? I occasionally remove them manually.

No. pending is just there because of 'atomic' requirements. We have to
create a directory, and put a file in it. And *then* rename it. If there
is a leftover pending directory, that is just a lock which was failed to
be taken.

Probably we are missing a place where we should be deleting the pending
directory if we fail to grab a lock.

> 
> T. Budiman
> Malaka9
> Bandung INA


John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060822/1d89f8e7/attachment.pgp