[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jgit-dev] TransportAmazonS3 concurrent push
|
On Wed, Oct 2, 2013 at 7:42 PM, James Yonan <james@xxxxxxxxxxx> wrote:
> On 02/10/2013 12:21, Shawn Pearce wrote:
>>
>> On Wed, Oct 2, 2013 at 10:57 AM, James Yonan <james@xxxxxxxxxxx> wrote:
>>>
>>> The docs for TransportAmazonS3 say "Multiple concurrent push operations
>>> may
>>> cause confusion in the repository state."
>>>
>>> Is "confusion" just a euphemism for corruption?
>>
>>
>> Yes. There is no locking, so there is no safe way to ensure your push
>> doesn't replace someone else's push. Pushes to S3 are essentially
>> always running with --force. It tries best effort to avoid a
>> non-fast-forward update, but once its read the value someone else can
>> replace it without you knowing, and then you replace it, last one
>> wins. :-)
>
>
> Just trying to understand the worst-case scenario here... So suppose that
> two people push at the same time, and the last one wins.
The first person also sees a successful message, so they believe their
commits were put in the repository. They were, briefly, before being
discarded by the winner. So the loser doesn't know they need to do the
pull/push cycle. The really bad thing is the loser getting a
successful message. :-)
> This post [1] ("Git requires minimal file locking...") implies that the
> "loser" could do a pull/push cycle to restore their lost push in the repo.
>
> Is this the case with jgit as well?
>
> [1]
> http://stackoverflow.com/questions/750765/concurrency-in-a-git-repo-on-a-network-shared-folder
Yes, the highest ranked answer is correct, and JGit follows the same
locking conventions and has the same behavior.
S3 is a bit like a system with no O_EXCL semantics, so the standard
locking protocol used by Git and JGit isn't supported there. Most
systems support O_EXCL and the locking protocol works in those places
to give the loser a failure message rather than a false success.