threads / discuss / 3315

git-cvsserver & push/commit atomically

Subject: git-cvsserver & push/commit atomically

## tl;dr

3 messages between Feb 12, 2006 and Feb 13, 2006.

replies: 2people: 3as markdown or json

Martin Langhoff· Feb 12, 2006, 23:50 UTC · lore

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

Johannes Schindelin· Feb 13, 2006, 00:17 UTC · re: Martin Langhoff · lore

Re: git-cvsserver & push/commit atomically

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

Randal L. Schwartz· Feb 13, 2006, 02:25 UTC · re: Johannes Schindelin · lore

Re: git-cvsserver & push/commit atomically

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