[PATCH 1 of 6 path intent] ui: add an intent to expandpath

[Gregory Szorc]

On 9/30/14 10:26 AM, Mads Kiilerich wrote:
> On 09/30/2014 07:18 PM, Gregory Szorc wrote:
>> On 9/30/14 9:53 AM, Mads Kiilerich wrote:
>>> On 09/30/2014 02:30 AM, Gregory Szorc wrote:
>>>> outgoing is read-only despite the association with push. In Mozilla's
>>>> use case, only people with push access (a subset) have access to the
>>>> push URL (SSH). Everybody has access to the HTTP endpoint. People
>>>> without SSH access should still be able to use outgoing. So using the
>>>> push/SSH URL for outgoing would be wrong in our case, even though it
>>>> is logically the most appropriate URL to use.
>>>
>>> I think you put it backwards and describe your current setup as a
>>> requirement.
>>>
>>> Yes, outgoing is a read-only (and very cheap - especially when using
>>> ssh) subset of push. It is intended to show exactly what will be pushed.
>>> Trying to treat them differently would be a confusing misfeature. I
>>> don't think Mercurial itself should do anything to encourage that
>>> misfeature - quite the opposite.
>>>
>>> In the setup you describe, people with push access should use ssh for
>>> outgoing, just like they do for push. People without push access should
>>> just use http for everything.
>>
>> We don't want to overload our SSH server. We have N>1 HTTP servers to
>> facilitate scaling. Therefore we'd prefer to use HTTP for all non-push
>> operations.
>
> Do you have any numbers to support that the load from users with push
> access running outgoing would be significant? I doubt it will make a
> real difference - and certainly not enough to justify the added
> complexity and breaking the users expectations.

No. However the principle of it is that we shouldn't be providing a 
vector to overwhelm our master if it can be avoided. We already have 
enough scaling problems: I'd prefer to not introduce another one.

That being said, in the grand scheme of things I doubt outgoing requests 
are frequent enough to cause any real world issue. That being said, our 
high-volume server is our "try" repo. And we're moving that to a 
bundle-based approach. That will generate a lot of outgoing requests. 
But we'll have a custom extension for that and we can pin the URL used 
for discovery easily enough.