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

[John Arbash Meinel]

T Budiman wrote:
>>> The situation that I'd love to see is to replace
>> svn with bzr but
>>> still allow people to work the same way (in a
>> centralized manner).
>>> That would mean that many developers are using
>> checkouts on multiple
>>> branches in that same repo at the same time.
> 
> I'm trying that in my workplace with 5 developers
> using  1 central repository and each using lightweight
> checkouts.

...

> 
> Yes, when someone is locking the repositories the
> other developers get locaking errors and has to wait
> (manually).
> 
>> 1) Shared repositories are simply a storage
>> optimization. If you really
>> run into lock conflicts on separate branches too
>> often, create more
>> repositories. In the ultimate case, everything could
>> be a standalone branch.
> 
> This could be done, but require extra effort when
> integrating work by different developers. I don't
> think this approach solve the problem.

Doesn't really require any extra work by anyone. If you are using a
single branch, then that is all you have. The discussion here is from
Robey, which is discussing having 1 shared repository with multiple
branches in it. This is equivalent to having individual branches.

It is true that when merging between them, you pay a performance
penalty. And you pay an even bigger one when creating a new branch. But
functionally they work the same.

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.


> 
>> 2) It is already possible to wait on a lock for a
>> short period of time.
>> We just need to update the code so that it doesn't
>> always puke right
>> away, but is given the opportunity to wait for a few
>> seconds before
>> failing. This mostly has implications based on how
>> long a lock is
>> expected to be held versus the frequency of commits.
> 
> This looks like a nice feature to have. This is what
> cvs do right?

What CVS does is only require that you be up-to-date for the single file
that you are changing. This is wrong, because it breaks all the concepts
of tree-wide integrity. In CVS you never have to have your whole tree
up-to-date. So what you check in, is frequently not what someone would
checkout if they tried to get your code. (SVN actually suffers from
this, too. But they push those cases down a little bit further).

> 
> Another and more serious problem is when some bzr
> operation failed (caused by network disconnection, for
> instance). Then the repository is still locked the
> that particular user. Then the other users can't use
> the repositories, since the lock file is owned by the
> first user. bzr clear-lock doesn't work with
> permission denied. So they need the first user or root
> password to delete the lock file.
> 
> Any thoughts on this?

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

There are issues about directories not maintaining the group sticky bit,
because of how we interact with the OpenSSH implementation of sftp (it
strips certain bits that we are trying to set).

If the directory is group writable, you should be able to break locks
taken out by another user.

If you find this doesn't help, please submit a bug here:
https://launchpad.net/products/bzr/+bugs

We will probably re-vamp our permissions code in a (hooefully soon)
release. To make it interoperate a little bit better.

For now, let us know if the above fixes your problem. We may need to
also create the lock directories so that they can be broken. We might be
creating them only user readable, so that when we go to peek and see who
is holding the lock, only the original owner can read them. And while
technically anyone could break the lock, we peek before we break, and
that is causing problems for you.

Do you know what your default umask is on the shared machine?

> 
> 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/64b28aa8/attachment.pgp