How much is Bitbucket largefiles support worth to you?

Pierre-Yves David pierre-yves.david at ens-lyon.org
Thu Feb 11 17:18:46 EST 2016



On 02/10/2016 07:48 PM, Sean Farley wrote:
>
> Gregory Szorc <gregory.szorc at gmail.com> writes:
>
>> On Tue, Feb 9, 2016 at 5:21 PM, Augie Fackler <raf at durin42.com> wrote:
>>
>>> (+mads for largefiles thoughts)
>>>
>>> On Tue, Feb 09, 2016 at 02:17:08PM -0800, Sean Farley wrote:
>>>> It should be apparent by now that we're working on Git LFS[1] support
>>>> for Bitbucket. For those that use largefiles, this should be good news.
>>>> I've tried to latch onto the work a teammate is doing for Git LFS but
>>>> unfortunately hit a roadblock.
>>>>
>>>> The gist is that we need to send a url to the client to tell it where to
>>>> upload the largefiles. This could almost be hacked in with http
>>>> redirection but SSH wouldn't be able to use that.
>>>>
>>>> Instead, I was going to ask the Mercurial community if someone could
>>>> implement this type of redirection (keeping authentication in mind). If
>>>> this happened, I could implement the server-side code to work with this.
>>>> Theoretically, a user could optionally use some other kind of backend
>>>> for the largefiles and still use Bitbucket for code hosting.
>>>
>>> I'm not a largefiles user, so bear with me. It sounds like the main
>>> (mercurial) server wants to be able to specify an alternate address
>>> (possibly also including protocol) for the largefiles operations,
>>> right?
>>>
>>> Any reason we can't add a pushkey entry for that, and just have modern
>>> clients know to check with the server for an advisory alternate
>>> largefiles URL? Sean, would that solve your needs?
>>>
>>
>> Or advertise it as a server capability. A benefit of that is there is no
>> extra round trip to obtain the URL since clients request capabilities as
>> part of the handshake at connection time.
>
> That wouldn't work. We need to send a url that contains some kind of
> auth token for S3 (or whatever we end up using for the backend). That
> token will expire and needs to be generated for the push.

Using capability seems a quite good idea indeed. I do not get the issue 
Sean is trying to point at as I'm not sure I see a significant 
difference between the capability and pushkey approach.

Cheers,

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list