From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Mon, 13 Feb 2006 00:17:23 GMT
Subject: Re: git-cvsserver & push/commit atomically
Message-ID: <Pine.LNX.4.63.0602130110590.21465@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <46a038f90602121550v4f487edfs788885a78c1b167@mail.gmail.com>

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