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

[Martin Pool]

On 21 Aug 2006, John Arbash Meinel <john at arbash-meinel.com> wrote:
> > 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.

Just to be clear, this is totally different from a conflict happening
because someone else committed before you and touched the same files. 

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

Yes, you can commit if someone else has in the interim committed to
other files.  This means that commits conflict less often, but on the
other hand you get committed trees that have never existed in a checkout
and so never been reviewed or tested.

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

I think there is already code to poll.  The main thing we need to fix is
to make it communicate more:

  waiting for lock on /foo/bar held by user at host process 123
  press Ctrl+C to interrupt...

  ^C 
  failed to acquire lock
  check that process 123 on host no longer exists, then use
  bzr break-lock to remove the lock

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

It will still need to hold off the client until the previous transaction
has completed.  But there are several effects, most of them good:

 - Reduced time to commit means a lower duty cycle and less chance of 
   contention

 - If the connection drops the server process can still release the
   lock, unless it dies or the whole machine stops

 - Possibly the server could only take the lock once all the data has 
   come across the network

However, it will still happen that some clients need to block waiting
for a previous commit.

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

Allowing commits to different files within a tree (like svn) would be a
traumatic model change, and one that I don't really like.  However it's
quite possible a smart server could allow near-simultaneous commits to
different branches within a repo.  

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

That was the current plan.  Progress report soon I promise.

-- 
Martin