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

[Augie Fackler]

On Tue, Sep 30, 2014 at 11:00:52AM -0700, Gregory Szorc wrote:
> 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.

FWIW, I can sort of see this making sense for things like lookaside
bundles. Think large, globally distributed company that doesn't have
enormous pipes to all their engineering offices - you could redirect
most pull traffic to a local replica transparently, but then do all
pushes to a central master, without having to do some sort of
complicated replica system.

> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel