want scheme://host/repo to access ~/repo

[Selene ToyKeeper]

As of bzr 1.3-1, there is no way to specify bzr+ssh URLs relative to a user's home dir. The syntax requires a full path:

  bzr+ssh://host/home/user/repo/

The sftp transport does support it, but in a different manner than most other systems:

  sftp://host/~/repo/

It would be nice to change the default to match other systems. For example:

  (svn) svn+ssh://host/repo
  (hg) ssh://host/repo
  (unison) ssh://host/repo

In those, a single slash between host and repo means relative to home, and a double slash starts at the root dir. This seems like a reasonable default, since most of the time users want a relative path, and the other cases are easily handled with an extra slash.

An example use for this is running a central repo server, with all repos under a "bzr" user. Users would then access the repo by adding a "mybzr" host alias in ~/.ssh/config, which specifies the correct host name and "bzr" user. Then pull a copy with "bzr branch bzr+ssh://mybzr/repo". The actual path to "repo" can then change as necessary on the server without affecting any users. Or, more flexible setups could be created, similar to what gitosis provides.

This also would allow switching between http:// repos and bzr+ssh:// repos without changing anything other than the protocol, since http already uses relative paths.

[Trevor Jim (trevor-research)]

The sftp:// URLs used by bzr actually conflict with the standard.

RFC 1738 says that ftp URLs are relative to the login directory.

So sftp://example.com/foo should refer to foo in the login directory,
but in bzr it refers to /foo.

To refer to /foo the standard says to use sftp://example.com//foo.

Can fix? :-)

[John A Meinel (jameinel)]

At one point bzr did use those urls. Having done that for a while, I can tell you it is a *bad* spec (and afterwards it actually changed). It is *very* hard to explain to people that "no, you need another slash in there", and for them to understand the difference between:

sftp://example.com/foo and sftp://example.com//foo

People were much better at understanding sftp://example.com/~/foo.

So I don't believe we are going to be switching, since we have had explicit experience with both forms.

[John A Meinel (jameinel)]

I should also point out that I'm not sure about "most of the time they want a relative path". It sort of depends on how things are laid out on the server, but I would argue that "most of the time" users actually want a server url in a shared location, such as "/srv/repository/branches". I would have thought that would be even more common in svn world. In Bazaar, since you can have your own branches wherever you want, I suppose it might be a little more common to keep them in your home dir.

I *do* believe we want to support bzr+ssh://host/~/, it just hasn't been implemented. One possibility might be for it to spawn "ssh host bzr --directory=~" rather than "--directory=/", I *think* that would actually work, as long as the server side code knows to expand "~" to the users home directory. (Or possibly just work it out directly.)

If you must have "bzr+ssh://host/relative" then you can actually use the "contrib/bzr_access" script in the source tree. I know in 1.6 it will work and causes all paths to be relative to whatever you configure in ~/.ssh/authorized_keys.

[Trevor Jim (trevor-research)]

Can you be more specific about

"and afterwards it actually changed" ??

I know that RFC 1738 was updated by RFC 3986, however,
that did not to my knowledge change the ftp URI scheme.

In fact RFC 4395, "Guidelines and Registration Procedures for New URI Schemes,"
says that IANA maintains the registry for URI schemes, and that
registry is here: http://www.iana.org/assignments/uri-schemes.html
and it lists RFC 1738 as the spec for ftp URIs.

I don't have an opinion on whether it is a good or bad or confusing scheme.
I think that not following a standard is confusing too.

[Selene ToyKeeper (toykeeper)]

Thanks, John. The contrib/bzr_access script does basically what I was looking for. It appears to implement an access method similar to what I've been using with svn/hg/git.

I think the bzr_access approach should be default for bzr+ssh, but adding support for ~ would be sufficient to close this bug.

Consistency is the main reason I think relative paths should be default. Other tools and other protocols use URLs relative to their home, or relative to their application-specific root, and bzr seems like the exception. For example, bzr's current behavior is a bit like hosting web content with URLs like:

  http://example.com/var/www/example.com/index.html

Exposing the full path to the user is a nice option, but seems like strange default behavior.

I know of two generally-accepted standards for URLs... bzr+ssh uses neither.

One style is what Trevor linked, used by http, unison, svn, hg, git, ftp, streaming media, pop3, imap, and dozens of other protocols...
  protocol://user@host/relative/path
  protocol://user@host//absolute/path
  protocol://user@host/~otheruser/path

The other is less popular, but shorter -- used by rsync, scp, mount (nfs), and bzr's launchpad plugin (without the 'user@' part)...
  user@host:relative/path
  user@host:/absolute/path
  user@host:~otheruser/path
  user@host:~/path

I realize it may be difficult to change to standard URLs at this point, because users with absolute URLs would have to reconfigure. To provide a gentle transition, bzr would probably need to check the relative path first, produce a warning if it fails, then check the absolute path.

[Selene ToyKeeper (toykeeper)]

If users complain about a double slash, it makes me wonder if the users are taking the wrong approach. I see two main possibilities -- single-user and shared:

  - If a remote branch is private, it probably resides somewhere in $HOME, and absolute paths become inconvenient.

    Example URL: bzr+ssh://myuser@host/home/myuser/project/trunk

  - Otherwise, if a remote branch is shared, posix group permissions are likely to cause problems, and a different approach may be recommended. Between varying umasks, multiple/default groups, ignored g+s permissions, and other factors, I've found that it's usually necessary to reset permissions on shared-write trees via cron. Even in good conditions, complex user/group access control isn't very feasible.

    Example URL: bzr+ssh://myuser@host/var/lib/bzr/project/trunk

All the usual problems in the shared case can be solved by the contrib/bzr_access approach. It seems like the "best practice" for sharing central bzr repositories over ssh, and best practices should usually be default behavior. As a bonus, it's consistent with how other SCM tools serve content over ssh.

    Example URL: bzr+ssh://bzr@host/project/trunk

I don't recall ever seeing someone use svn+ssh://host//var/lib/svn/project/trunk, but I see svn+ssh://svn@host/project/trunk all the time. The former just has too many complications. The last time I saw anyone use that approach was back when CVS was king.

Is there a popular and recommended usage model which makes use of bzr+ssh and absolute paths? Or, is there some reason the bzr_access approach should not be encouraged by default?

For the purposes of this bug, the issue is merely whether '//' or '/~/' is less inconvenient. As far as I can tell, '//' seems like a 'lesser evil' because relative paths are a better idea most of the time, and standards-compliance avoids confusion. But I may not see the whole picture.

[Andrew Bennetts (spiv)]

See also bug 109143, "hpss does not support ~ (tilde) for home dir access on bzr:// or bzr+ssh://"

[Martin Pool (mbp)]

There seem to be two parts of this bug: that there should be some syntax for homedir paths, and that homedir-relative should be the default. The first part is a dupe of bug 109143. I'm inclined to say that the other part of it should be closed as wontfix: we tried homedir-relative by default, we didn't like it, and there are plenty of other precedents for using the tilde.

Given there is no single standard, I think having the explicit tilde at least makes it clear what is meant, while //host/thing/ depends on knowing/guessing how the application will interpret it.

In general http:// urls are going to be relative to a server-defined root with no clear relationship to either the filesystem root or the user's root directory.