[PATCH 1 of 1] url: added support for scp/rsync style URLs for ssh

Matt Mackall mpm at selenic.com
Tue Apr 19 11:06:45 CDT 2011


On Tue, 2011-04-19 at 11:11 +0200, Dirkjan Ochtman wrote:
> On Fri, Apr 8, 2011 at 10:22, Thomas Arendsen Hein <thomas at intevation.de> wrote:
> > Ry4an said on IRC that we should count him as a fan, because the
> > double // in absolute ssh URLs is in the top two of reported
> > problems for him.
> >
> > mpm said that he is -.5 on this and likes to see more discussion
> > about the robustness of the guessing.
> >
> > So everyone who likes to have this feature should comment now!
> 
> Let's revive this discussion a bit (see also on IRC).
> 
> I still dislike the idea, for several reasons:
> 
> 1. We already have ssh://, this is just added clutter
> 2. I thoroughly prefer the explicit protocol, it makes it clear what will happen
> 3. I think host:path-style paths are confusing, because I'm used to :
> introducing a port

A few observations:

- rsync/rcp/scp are one-protocol affairs, so having a protocol-less path
specifier mostly makes sense (though arguably rsync suffered for not
having a way to specify ssh vs rsh _in the path_ in the early days).

- rcp/scp syntax was -always- unfortunate because it was too easy to run
afoul of (everyone who's used it regularly has had to delete countless
files named user at host because they hit return before the colon)

- rsync's syntax for when its communicating with a daemon vs a remote
shell (:: or rsync://) is an ugly hack

- there's no way to specify an alternate port in this syntax.

- Mercurial is not a one-protocol tool and never has been and it was
invented in an era when everyone knew how to work with a multi-protocol
tool: URLs.

- the two syntaxes are obviously lexically incompatible and adding
further heuristic hacks to our nice new _url_ class to support them
isn't terribly pretty


I've been using rcp and friends since.. the 80s and I can't say I've
ever thought "hmmm, this would be better if it took rcp paths".

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list