From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Sun, 12 Feb 2006 23:50:47 GMT
Subject: git-cvsserver & push/commit atomically
Message-ID: <46a038f90602121550v4f487edfs788885a78c1b167@mail.gmail.com>

I am trying to figure out a safe way to lock the git repo to prevent
clients pushing to it while someone else (via git-cvsserver.pl) is
manipulating it. Push and commit are *mostly* transactional it seems,
but I'm not 100% clear on how the head update gets updated safely.

Ahhhh. Hmmm. Reading git-receive-pack.c update(), it seems that we
have to mimic that behaviour in Perl. The semantics are a bit weird
for me -- not used to safe C open()s. From what I read, it looks like
it

 - precondition: all the relevant objects are already in the repo
 - reads old sha1
 - creates repo.git/refs/<headname>.lock file with new sha1
 - compares old and current head
 - runs update hooks
 - renames repo.git/refs/<headname>.lock into repo.git/refs/<headname>

So it is mostly race-safe, except for the window while we are running
update hooks. Only a misbehaving implementation that doesn't fail on
the creation of repo.git/refs/<headname>.lock  would affect us there,
though. Would locking repo.git/refs/<headname> make sense?

git-cvsserver commits are likely to be slow (not only likely, they
_are_ slow right now), so we need a way to block other clients for a
relatively long time.

cheers,


martin