shorter bzr+ssh url syntax

[Vincent Ladeuil]

>>>>> "robert" == Robert Collins <robertc at robertcollins.net> writes:

    robert> On Thu, 2007-06-21 at 11:15 +1000, Martin Pool wrote:
    >> https://bugs.launchpad.net/bugs/121195
    >> 
    >> Since this seems to need some discussion here it is on the list.
    >> 
    >> "bzr+ssh://" is 12 keystrokes (counting shifts) to type, which is a
    >> bit high if it is to become the standard way of getting to remote
    >> branches.

Then I'll say: "let's discuss that again *when* ssh has become
the standard way of getting branches". 

IMHO:

- http is and will, for a long time, be the standard way of
  getting branches,

- [s]ftp is and will, for a long time be the standard way of
  committing to branches,

- bzr+http: may become the standard way of getting and committing
  to branches (and I strongly hope so).

- bzr+ssh: may become the preferred way of getting and committing
  to branches for developers who *can* configure their own server
  (which may be a tiny fraction of the user base).

    >> Some options include:

    robert> bzr+ssh://bazaar.launchpad.net/~username/demoproject/trunk

    robert> What percentage of the total path is allocated to bzr+ssh:// ?

And when does the user *have* to type it considering that it
will be stored in 'locations.conf' ?

    >> 0- leave it as it is

    robert> My vote is for this option.

Same here.

    >> 1- ssh:// ...

    robert> An advantage of bzr+ssh is that browsers can be taught

Good point. No, more, neat point ;)

And a very strong argument against going away from the URL syntax
which is a sort of guarantee that bzr branches and repositories
can be addressed in a coherent way by foreign tools.

    >> 2- user at host:patch or host:path -- concise and consistent with rsync,
    >> darcs, other systems; if no username is given this is slightly
    >> ambiguous with other url schemes but can still be discerned unless the
    >> hostname is a scheme name

Bad feeling about that one here, URL syntax is good, let's stick
with it and let's avoid magical tricks.

bzr uses:
- URLs
- decorators

Reducing the name space is a tough call. I strongly prefer
relying on the URI syntax, well defined, established and known by
everybody.

<snip/>

    robert> Given that we remember branch urls, that we have a configuration system
    robert> that can generate all the urls for branches in a common prefix for the
    robert> user, that bzr+ssh:// is a *small* fraction of the data required to talk
    robert> about everything else, I think its a mistake to try to shrink it
    robert> massively. Better to do what ssh itself does and offer a config system
    robert> to provide nicknames for hosts that can include:
    robert>  host name aliases
    robert>  protocol selection 
    robert>  change the default path 
    robert>  credentials

    robert> This would let *much* shorter paths be specified by the user, while
    robert> allowing bzr to still generate correct external urls and so on.

On top of that (which is ssh specific), it should be easy to
create a 'my' plugin doing aliasing along the lines of:

,----
| # Getting projects from launchpad
| lpr = http://bazaar.launchpad.net/~bzr
| # Commiting
| lpw = sftp://joe@bazaar.launchpad.net/~bzr
| # home server
| home = bzr+ssh://joel:password@localhost:1234/src/repo
`----

which will provide urls for:

,----
| bzr branch my:lpr/bzr.dev
| bzr commit my:lpw/bzr.dev
| 
| bzr log my:home/pet-project
`----

if we really want to provide shortcuts.

Also, since we are talking about protocols and decorators, there
is some inconsistency in our choices:

bzr+ssh, bzr+http[s] /against/ http[s]+urllib, http[s]+pycurl

I'll favor enforcing:

[decorator+]* scheme [+implementation]*

which imply using:

ssh+bzr, http+bzr /instead of/ bzr+ssh, bzr+http

         Vincent