sftp oddities

[John Arbash Meinel]

Jeff Rose wrote:
> On Tue, 2005-12-20 at 12:27 +0100, Jan Hudec wrote:
> 
>>On Tue, Dec 20, 2005 at 11:54:22 +0100, Jeff Rose wrote:
>>
>>>Hello again,
>>>  I was thinking it could be helpful to bring up issues as we jump into
>>>bazaar, but if this isn't the right forum let me know.  Both of my
>>>roommates and I are grad students in CS with years of cvs/svn under our
>>>belts, and we probably represent the type of people you hope to bring to
>>>bazaar as time goes on.  Hopefully our perspectives can be
>>>constructive...
>>>
>>>1. Why does pushing and branching with sftp use an odd url that doesn't
>>>correspond with what people already know about sftp?  Why not use a
>>>colon after the hostname, and then if you have a slash it goes to the
>>
>>Because it does not work for URL. Colon after hostname is followed by port
>>there (It's not mandatory anywhere, so it /could/ be done -- but it would not
>>be more expectable).
> 
> 
> I don't know about official URL syntax, but I just wanted to let you
> know what someone "from the outside" thinks when they first use the
> tool.  If you are going to be using url's (er, addresses) that are
> different from tools people are familiar with then it is especially
> important to have really informative error messages and examples in
> help.  Since bzr supports pluggable transports maybe they could
> implement a method that spits out an example using their transport or
> something like that...?
> 

Well, part of the issue is that you are coming into the development
codebase, so not everything has settled yet :)

In general, bzr wants to use URL's, of which scp's notation of
user at host:/directory is not a real url. URL's have the capability of
expressing all of the pieces internally, as:

protocol://user:password@host:port/path/to/something

That makes things consistent between http, sftp, ftp, (possibly future
rsync code), etc.
There was an IETF draft saying that: sftp://host/path should be a
relative path (typically to a users home directory), and that to get an
absolute path you needed sftp://host/%2Fpath, the %2F being an escaping
to secretly pass '/' to the remote machine.

I think our general consensus was that it is nicer to go back to:
sftp://host/absolute/path
And wait for IETF to publish a new draft, while we recommend something like:
sftp://host/~relative/path

> 
>>>root of the fs, like the normal utils?
>>>
>>>sftp://foo.com:/home/myfriend/code/project
>>
>>Because things like:
>>sftp://foo.com:443/home/myfriend/code/project
>>need to be possible too.
> 
> 
> Well, sftp should be running on the correct port.  Otherwise in the very
> rare case where its on a non-standard port something like this could
> work:
> 
> bzr branch -p 443 sftp://foo.com:/home/myfriend/code/project
> 

That would work, but in the above you are *almost* using URLs, so really
we should try and unify into using standard url syntax.

> 
>>>otherwise you have to do this, which seems pretty weird:
>>>
>>>sftp://foo.com/../myfriend/code/project
>>
>>That's invalid URL! It's forbidden to have . and .. components in URL.
>>
>>Well, there is the issue with latest sftp url draft that says:
>>sftp://host/path/relative/to/users/home
>>sftp://host/%2Fabsolute/path
>>The draft is expired now. AFAIK it's only followed by mercurial and bzr now.
>>There was talk about switching to:
>>sftp://host/absolute/path
>>sftp://host/~/path/relative/to/users/home
>>but I don't know whether it's already implemented.
> 
> 
> Currently the forbidden url works:
> -------------------------------------
> rosejn at jive:~/tmp$ bzr branch
> sftp://research.inf.unisi.ch/../mesnage/Projects/iBib/development
> ibib.dev
> Branched 1 revision(s).
> -----------------------------------
> 

Allowing a '..' in a URL is a bug, since it is dangerous behavior and
breaks the URL spec.
The recommended way *right now* is to use a second slash, so you have:
sftp://host//absolute/path
(bzr will convert that into sftp://host/%2Fabsolute/path internally).

> 
> 
>>>  Pushing a fresh tree (at least with sftp) prints a warning that makes
>>>you think it has failed:
>>>
>>>--------------------------------------------
>>>rosejn at jive:~/code/icalendar$ bzr push
>>>sftp://research.inf.unisi.ch/code/icalendar
>>>bzr: WARNING: Unable to update the working tree of:
>>>sftp://research.inf.unisi.ch/code/icalendar
>>>7 revision(s) pushed.
>>>--------------------------------------------
>>>
>>>Then checking the remote branch to see if it did indeed work, we find an
>>>empty project directory.  Branching seems to work fine though, so I
>>>guess it rebuilds the working tree when you pull it down?
>>
>>It does not build the working directory on the server - just as it says.
>>Never. But it builds it locally when you branch from it.
> 
> 
> Hmmm.  It says "WARNING", which doesn't sound like behavior that is
> supposed to occur.  If that is incorrect then maybe it can be my first
> patch :-)

Well, we could downgrade it from a warning. bzr doesn't support remote
working directories, because it may have to do merging, which can
generate conflicts, and you don't generally have a way to resolve them.

A notice needs to be made, otherwise you do
	bzr push sftp://somewhere/else
And you end up with what looks like and empty directory. (Since .bzr is
hidden)

If you want, you probably can change 'warning' to 'note'. But generally
stay away from using 'print' inside the bzrlib code. We have it in there
far to often already, for something that wants to be a library.

> 
> Peace,
> Jeff

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051220/fde6e81b/attachment.pgp