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

[John Arbash Meinel]

Jan Hudec wrote:

...

>> (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.
> 
> Well, I can imagine this being implemented even for non-singleton
> server, but it's quite a bit of programming.
> 
> Basically the idea is, that the repository lock could be somehow made a
> shared-lock (this seems to me would be the hardest part).
> 
> Clients not capable of using fcntl lock would lock it exclusively and do
> whatever they do now. This means clients using dumb transports and
> clients accessing over network filesystems that don't support locking.

The hardest part is making clients using fcntl interact properly with
clients that can't. Such that clients who are smart about it, realize
that the branch/repository is locked in shared mode, but other clients
would only think it was exclusive mode.


> 
> Clients capable of using them would lock shared and then fcntl lock
> individual files they need to access. They would either need to lock one
> knit+index at a time or lock them in defined order (to avoid deadlocks,
> though posix locks are *supposed* to support deadlock detection).

This was an initial thought back with Weaves, and a way that we could
properly support hardlinked knit files. The problem is that it
distinguishes local branches from remote branches. Which is sort of
okay, but at a higher level my local branch may be your remote branch,
just that I'm directly logged into the shared machine.

> 
> They would have to wait for the knit locks to provide a sane semantics.
> Waiting on the branch lock does not make sense, because we know we will
> be out of date when it's released.
> 
> Than any local clients (which includes smart servers) would than be able
> to commit to distinct branches in parallel.
> 
> --------------------------------------------------------------------------------
>                   				- Jan Hudec `Bulb' <bulb at ucw.cz>

Completely true, but hard to do if you want simple remote filesystem
support. The sftp v6 draft looks very promising for something like this,
since it supports OS-level locks over SFTP. But nobody uses a v6
implementation of the spec. So in the mean time, we basically need a
custom server that can use local semantics over a remote connection. And
that is what Martin an Andrew Bennetts are working on.

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/20060824/22077f5c/attachment.pgp