Re: [jgit-dev] TransportAmazonS3 concurrent push

[Robin Rosenberg <robin.rosenberg@xxxxxxxxxx>]

----- Ursprungligt meddelande -----
> Från: "Shawn Pearce" <spearce@xxxxxxxxxxx>
> Till: "James Yonan" <james@xxxxxxxxxxx>
> Kopia: "JGit Developers list" <jgit-dev@xxxxxxxxxxx>
> Skickat: torsdag, 3 okt 2013 6:07:13
> Ämne: 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.

A horribly hackish "solution". Assuimg the ref update is normally a quick
operation. Sleep much longer that that after the update, then read back
and see if it's unchanged. If not report failure, else report "likely success".

-- robin