git-cvsserver & push/commit atomically

git-cvsserver & push/commit atomically

[Martin Langhoff]

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

Re: git-cvsserver & push/commit atomically

[Johannes Schindelin]

Hi,

On Mon, 13 Feb 2006, Martin Langhoff wrote:

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

Correct. The filesystem way to lock is to create a lock file and fail if 
it already exists. Since you are doing something akin to git-commit, I 
think you *must* lock repo.git/refs/<headname>.

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

I don't think there is a way around that. Of course, you could write the 
objects first without locking. But then you probably have loose objects in 
the repository if the commit fails due to another commit in the meantime.

<becomessweatyhands>
	BTW when are we going to see git-cvsserver?
</becomessweatyhands>

Ciao,
Dscho

Re: git-cvsserver & push/commit atomically

[Randal L. Schwartz]

>>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Johannes> Correct. The filesystem way to lock is to create a lock file and
Johannes> fail if it already exists.

Unless NFS has been fixed, that's not an atomic operation over NFS.  Might not
matter here, but important to note if this is your first time seeing this lock
strategy.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!