Re: git-cvsserver & push/commit atomically

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Feb 13, 2006, 00:17 UTC
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:

Show 11 quoted lines

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