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

Mike Hommey mh at glandium.org
Fri Oct 17 20:13:10 CDT 2014


On Tue, Sep 30, 2014 at 07:26:22PM +0200, 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.

It's not all about the servers. As a user I find it annoying to have to
open a ssh connection (which usually means typing a passphrase) to use
things like outgoing("foo") in a revset, or simply the hg outgoing
command.

Mike


More information about the Mercurial-devel mailing list