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

[Jan Hudec]

On Mon, Aug 21, 2006 at 03:19:16PM -0500, John Arbash Meinel wrote:
> [...]
> 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:
> 
> [...]
> 
> (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.

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

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>