Accept "ssh://" as a shortcut for "bzr+ssh://" URLs

Do we still need the // part? Or can we use just ssh:whatever

I was mastaken in waiting on the party. If I was advertising for to help and
find a team or make a team. I would expect if they made a type 0 or
something that was critical and high it would not save the trash some were
and them say I'm and tired let ea.

On 6/19/07, Steve Alexander <email address hidden> wrote:
>
> Do we still need the // part? Or can we use just ssh:whatever
>
> --
> Change "bzr+ssh://" URLs to "ssh://"
> https://bugs.launchpad.net/bugs/121195
> You received this bug notification because you are a member of Bazaar
> Developers, which is the registrant for Bazaar.
>

--
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFFkcN7yXWcajQQndYRAgbqAKCMyXN9Jx4g0X7jocg+aUSFz0x4LwCgrURW
eGtqLjpzQVYa9+gzpCRtB84=
=zrpM
-----END PGP SIGNATURE-----

Seems to me if you still want modules like urlparse to be able to parse bzr urls, you want to keep the //. OTOH, neither 'ssh' nor 'bzr+ssh' are in urlparse's uses_netloc array, so I'm not sure how much it would help anyway.

A hack-around for Python is:

import urlparse
urlparse.uses_netloc.append('bzr+ssh')

but that is pretty gross.

This really should be a mailing list discussion, not a bug report discussion.
I think it would be reasonable to switch to ssh://, there is some ambiguity because of foreign branch support, but no more than svn+http:// et al.

We already use the 'netloc' hack, because we have sftp:// and http+urllib:// and bzr+ssh:// and a lot of other URL protocols and 'netloc' seems extra restrictive about what it will consider using the user@host portion. (We wrap it into a function of bzrlib.transport.register_urlparse_netloc_protocol, which does a double-register check.)

I would prefer for us to continue using "proto://user@host/absolute/path/" for the time being, we can do "proto:user@host" though that causes problems if you ever have paths that genuinely contain a ":" character. On Windows you end up with "C:/", though we can detect that as a single character "protocol" when running on a windows variant (cygwin?).

I agree with John : This is in specification and design territory. Its not an obvious defect (in fact I don't think its a defect - bzr does not use 'ssh' - a SSH: URL is one I would expect to fire up a terminal emulator over the ssh protocol, just like telnet: urls fire up a terminal emulator over telnet.

Lets take this to the list please, if we can't just reject it out of hand as a bad idea.

The repetition of 'bzr' in the command makes for a poor UI:

  bzr branch bzr+ssh://whatever

I disagree with Robert about an expectation that ssh: would be for terminal emulation. That's like saying that you expect http: to be only for web pages. Yet, we use http: URLs for web pages, and also for bzr data. We don't say bzr+http.

On Wed, 2007-06-20 at 09:08 +0000, Steve Alexander wrote:
> The repetition of 'bzr' in the command makes for a poor UI:
>
> bzr branch bzr+ssh://whatever
>
> I disagree with Robert about an expectation that ssh: would be for
> terminal emulation. That's like saying that you expect http: to be only
> for web pages. Yet, we use http: URLs for web pages, and also for bzr
> data. We don't say bzr+http.

In fact we have 'bzr+http' to indicate that you want to use the smart
server tunnelled over http. And when we say 'http' we give up the
ability for url handlers to hand off to bzr automatically, which is IMO
a shame - but a reasonable tradeoff when we are just using http.

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

I think giving an ssh url would be reasonably understood to mean
"bazaar over ssh", not "start a terminal".

But beyond that, we can use "user@host:relpath" as short hand,
similarly to rsync and darcs, amongst others. We would just need to
be sure that bzr+ssh really is the standard transport. (Rather than
say bzr+https or something.)

On Thu, 2007-06-21 at 00:30 +0000, Martin Pool wrote:
> I think giving an ssh url would be reasonably understood to mean
> "bazaar over ssh", not "start a terminal".
>
> But beyond that, we can use "user@host:relpath" as short hand,
> similarly to rsync and darcs, amongst others. We would just need to
> be sure that bzr+ssh really is the standard transport. (Rather than
> say bzr+https or something.)

Can we *please* take this to the list for further discussion?

--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

Through the fix for bug 330535 in 1.13, if you now give an ssh url bzr will suggest that you should use bzr+ssh://. I'm going to leave this open though because people still want it to accept ssh://

I split out bug 337456 for USER@HOST syntax.

I don't think the comparison to http:// is correct here; http:// without svn+ or bzr+ prefix works fine, and bzr will find the right one to use. That's not the case for bzr+ssh://, which implies the /current/ smart server protocol.

Reconsidering this, I think ssh:// should Do The Right thing and attempt to use whatever is appropriate to use over ssh for a particular location:

* if bzr is installed on the remote machine, it should use bzr+ssh://
* if sftp is available it should use sftp

(perhaps we can also support svn+ssh:// and git+ssh:// by checking if the remote location has a .svn or .git directory)

On Mon, May 04, 2009 at 10:59:09PM -0000, Jelmer Vernooij wrote:
> Reconsidering this, I think ssh:// should Do The Right thing and attempt
> to use whatever is appropriate to use over ssh for a particular
> location:
>
> * if bzr is installed on the remote machine, it should use bzr+ssh://
> * if sftp is available it should use sftp

If it does guessing like that, it might be nice if it cached the result
of the guess, otherwise that'd be a lot of round-trips (and an extra SSH
session startup!) at the start of every connection to the remote branch.