Re: [Gnu-arch-users] "virtual" archives in arch

[Mirian Crzig Lennox]

address@hidden (Charles Duffy) writes:
>
> Err, you *are* aware that pserver launches a different process for each
> user who's connected, and uses pretty much only file- and
> directory-level locks (as opposed to full-repository locks), such that
> different users can be changing different files in the same pserver
> repository at once, right?

I know.  I never said it was wonderful; in fact, it's the barest
minimum one can get away with.

> pserver does *NOT* buy repository-level atomicity.

What it buys is transaction-level commit atomicity.  For example, if a
client wants to commit changes to foo.c, bar.c and baz.c, it must
first specify the entire list to the pserver before the latter takes
any action at all.  Then the pserver attempts to lock all three files;
if it can't lock all three the transaction fails.  Then it checks that
all three of the client's commits will succeed; if even one would fail
they all fail.  Only then are the commits actually performed, the
files unlocked and the client notified of success.

As you observe, this isn't sufficient to provide the kind of atomicity
that Arch expects, because Arch would reject that commit even if an
unrelated file were committed by a third party.  However, it does get
close enough to provide a consistent view of the repository to Arch.

cheers,
Mirian