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

Gregory Szorc gregory.szorc at gmail.com
Tue Sep 30 12:18:35 CDT 2014


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.

>> To further complicate matters, our HTTP layer is currently rejecting
>> some Mercurial HTTP requests because the encoding of 100+ heads during
>> discovery is exceeding HTTP header limits.
>
> We only see that problem when people have full clones with all the
> gazillion of heads that they never will have any use for. Do you support
> that case or do you see it in other cases as well?

We see problems with N < 1000 heads. (This is separate from the N > 
10000 heads problem we have with Try.) If you have checked out the 
Firefox repositories with each release on its own branch/head, you get 
several hundred heads. Along that vein, we're considering doing "fake 
merges" to reduce the number of heads in our repos to mitigate this problem.


More information about the Mercurial-devel mailing list