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

[John Arbash Meinel]

Erik Bågfors wrote:
> Hi.
> 
> A few times something has happened that I wanted to mail about a long
> time ago, but never did.
> 
> I have a --trees repo with bzr.dev and bzr.0.9 and .....
> What has happened to my many times is that I've been trying to pull
> into multiple of these branches at the same time, only to get a
> message saying that the repository is locked (with a pretty cryptic
> message, that I can't remember right now).
> 
> I don't think this is very good, because I get this problem when it's
> just me with multiple branches in a repo.  What if we are multiple
> developers using multiple branches in the same repo?  This could scale
> and become a real problem then I think.

You always have this problem when you are trying to share a location.

> 
> 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 think that locking will become a serious problem then.   I haven't
> tried to do this yet, but it should be fairly easy to test what
> happens.

svn has the same problem. If 2 people try to commit at the same time,
they can cause a conflict, and have their commit fail.

cvs has this problem, but has an even bigger bug that commit is not
atomic, so when you run into a race condition, it might be that half of
your files succeeded, but the other half did not.

Now, it might be that svn follows the cvs model that you only need to
not conflict on the files that you are actually changing. In some ways,
I would think it has to, because of how it mixes the branch namespace in
with the filesystem namespace. I know you can have part of your
filesystem out of date, and svn won't care. While bzr requires all the
files you are working on to be at the same revision. (svn will let you
update 1 file to an old revision, and afterwards won't report that it is
out of date. Maybe it would complain if you make a change and try to commit)


> 
> Has anyone put any thoughts into this? Will this become a real problem
> in the scenario above?

There are a few possibilities.

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.

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.

3) If a smart server was running as a singleton on the remote end (as in
not spawned for every connection), it is possible for it to be the only
one holding the locks. And it can handle serializing the additions to
the repository.
Without a singleton on the repository side, the only serialization
possible is a whole repository lock, because you don't know if you are
updating the same files that the other user is updating. With a
singleton, it doesn't matter. It can just make sure that it only writes
one update at a time. Or it can get fancy, and allow client A to write
to files 1,2,3 while client B is writing to 4,5,6.

Summary:

Yes, we have thought about it. (1) is currently available without any
code changes. (2) is a reasonable, small code change, that will help
prevent spurious failures in a large number of cases. I'm thinking that
we should check if locked, if we are, check every second for 10 seconds,
and then fail if we are still locked. The lock timeout could even be
user configured in the case that some repositories are further away/more
heavily in use/take longer to commit to.

(3) is something that we are looking to implement for other performance
benefits. It won't be in 0.10, it might be in 0.11. Though I don't know
that it will support concurrency. I don't know the details of the
current implementation, but it certainly could be a single process is
spawned as part of every ssh connection.

> 
> Regards,
> Erik (on his honeymoon... not kidding :) )

Why are you posting from your honeymoon? Congratulations... but really
you should have more important things to do than post to bazaar.

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/20060821/02b0246c/attachment.pgp