From: Marc Branchaud <marcnarc@xiplink•com>
To: Jeff King <peff@peff•net>
Cc: Git Mailing List <git@vger•kernel.org>
Subject: Re: Concurrent pushes updating the same ref
Date: Mon, 10 Jan 2011 17:14:01 -0500 [thread overview]
Message-ID: <4D2B84A9.4040603@xiplink.com> (raw)
In-Reply-To: <4D25F80F.3050604@xiplink.com>
On 11-01-06 12:12 PM, Marc Branchaud wrote:
> On 11-01-06 11:30 AM, Jeff King wrote:
>> On Thu, Jan 06, 2011 at 10:46:38AM -0500, Marc Branchaud wrote:
>>
>>> fatal: Unable to create
>>> '/usr/xiplink/git/public/Main.git/refs/builds/3.3.0-3.lock': File exists.
>>> If no other git process is currently running, this probably means a
>>> git process crashed in this repository earlier. Make sure no other git
>>> process is running and remove the file manually to continue.
>>> fatal: The remote end hung up unexpectedly
>>>
>>> I think the cause is pretty obvious, and in a normal interactive situation
>>> the solution would be to simply try again. But in a script trying again
>>> isn't so straightforward.
>>>
>>> So I'm wondering if there's any sense or desire to make git a little more
>>> flexible here. Maybe teach it to wait and try again once or twice when it
>>> sees a lock file. I presume that normally a ref lock file should disappear
>>> pretty quickly, so there shouldn't be a need to wait very long.
>>
>> Yeah, we probably should try again. The simplest possible (and untested)
>> patch is below. However, a few caveats:
>>
>> 1. This patch unconditionally retries for all lock files. Do all
>> callers want that? I wonder if there are any exploratory lock
>> acquisitions that would rather return immediately than have some
>> delay.
>>
>> 2. The number of tries and sleep time are pulled out of a hat.
>>
>> 3. Even with retries, I don't know if you will get the behavior you
>> want. The lock procedure for refs is:
>>
>> 1. get the lock
>> 2. check and remember the sha1
>> 3. release the lock
>> 4. do some long-running work (like the actual push)
>> 5. get the lock
>> 6. check that the sha1 is the same as the remembered one
>> 7. update the sha1
>> 8. release the lock
>>
>> Right now you are getting contention on the lock itself. But may
>> you not also run afoul of step (6) above? That is, one push updates
>> the ref from A to B, then the other one in attempting to go from A
>> to B sees that it has already changed to B under our feet and
>> complains?
>
> Could not anything run afoul of step (6)? Who knows what might happen in
> step (4)...
>
> However, in my particular case I'm using a "force" refspec:
>
> git push origin +HEAD:refs/builds/${TAG}
>
> so (as Shawn says) step (6) shouldn't matter, right? Plus, all the
> concurrent pushes are setting the ref to the same value anyway.
Well, after modifying my build script to ignore failed pushes, I do
occasionally see failures like this:
remote: fatal: Invalid revision range
0000000000000000000000000000000000000000..1c58dc4c3fdd9475d26d0eb797cc096fb622a594
error: Ref refs/builds/3.3.0-9 is at 1c58dc4c3fdd9475d26d0eb797cc096fb622a594
but expected 0000000000000000000000000000000000000000
remote: error: failed to lock refs/builds/3.3.0-9
So I guess even the "force" refspec is getting blocked by step 6.
FYI, the repo receiving the push is running git 1.7.1.
M.
next prev parent reply other threads:[~2011-01-10 22:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-06 15:46 Concurrent pushes updating the same ref Marc Branchaud
2011-01-06 16:30 ` Jeff King
2011-01-06 16:48 ` Shawn Pearce
2011-01-06 17:28 ` Ilari Liusvaara
2011-01-06 17:12 ` Marc Branchaud
2011-01-10 22:14 ` Marc Branchaud [this message]
2011-01-06 19:37 ` Junio C Hamano
2011-01-06 21:51 ` Marc Branchaud
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D2B84A9.4040603@xiplink.com \
--to=marcnarc@xiplink$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=peff@peff$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox