Comment 8 for bug 109143

Ok, I'm working on this again. The main difficulty I see with translating ~/ on the server is making sure we don't accidentally allow access to $HOME if it wouldn't be allowed without this feature. e.g. adding this feature shouldn't silently cause existing inetd configurations (or OpenSSH authorized_keys) that specify --directory=/foo/bar to start serving something outside /foo/bar.

I think the way to do this is to add another argument to SmartServerRequest's constructor giving the relative path to use to translate an initial ~ path segment. If not specified, ~ will not be treated specially (which still leaves the possibility for a custom transport implementation for backing transport to handle it specially if desired). Then "bzr serve" can look to see if $HOME is inside the specified --directory, and if so, pass this extra argument.

This will satisfy the main motiviation, which is to make bzr+ssh://host/~/... do something useful automatically. It may also be useful for bzr:// and bzr+http too, which is nice.

Perhaps we will want to allow users to pass --homedir to bzr serve rather than hardcoding to $HOME, but we can do that easily enough later if/when we get some use cases for more control.