[MERGE] bzr help locationspec
Aaron Bentley
aaron.bentley at utoronto.ca
Thu Jan 18 00:22:55 GMT 2007
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Goffredo Baroncelli wrote:
> ghigo at venice:~/bazaar/repo/bzr-help-topics-transport$ ./bzr help transport
I also think "transport" is a very poor topic name. My favourite would
be "locations", I'd accept "urls", but "protocol" and "transport" aren't
good topic names, because they're not very discoverable.
> * Transport: <default>, file://
> This is the transport agent for local filesystem access.
I don't think "transport agent" is useful terminology. The word
"transport" is both a verb and a noun, and we use it as a noun.
Any description of the locations Bazaar accepts should include directory
paths as well as file:// urls.
"<default>" is not useful information.
> * Transport: aftp://, ftp://
> This is the transport agent for ftp:// access.
This is too vague. Either aftp should have its own section, or you
should describe here how it differs from ftp.
> * Transport: bzr+http://
> Just a way to connect between a bzr+http:// url and http://.
>
> This connection operates slightly differently than the SmartSSHTransport.
> It uses a plain http:// transport underneath, which defines what remote
> .bzr/smart URL we are connected to. From there, all paths that are sent
> are
> sent as relative paths, this way, the remote side can properly
> de-reference them, since it is likely doing rewrite rules to translate an
> HTTP path into a local path.
This is not true; the patch to do this was never merged:
http://bundlebuggy.aaronbentley.com/request/%3C20070104062000.GE5903@steerpike.home.puzzling.org%3E
Also, the description shouldn't include internal details such as
SmartSSHTransport.
> * Transport: bzr+ssh://
> Connection to smart server over SSH.
>
> This is essentially just a factory to get 'RemoteTransport(url,
> SmartSSHClientMedium).
Again, way too much info. The first line is enough.
> * Transport: bzr://
> Connection to smart server over plain tcp.
>
> This is essentially just a factory to get 'RemoteTransport(url,
> SmartTCPClientMedium).
Too much info again.
> * Transport: http+pycurl://, http://, https+pycurl://, https://
> http client transport using pycurl
>
> PyCurl is a Python binding to the C "curl" multiprotocol client.
>
> This transport can be significantly faster than the builtin
> Python client. Advantages include: DNS caching.
Is that still an advantage? I thought the urllib transport had closed
the gap, and there were virtually no advantages to pycurl.
> * Transport: http+urllib://, http://, https+urllib://, https://
> Python urllib transport for http and https.
This is wrong. http is not urllib; it varies, depending on whether you
have pycurl installed.
> * Transport: sftp://
> Transport implementation for SFTP access.
It might be useful to note that it works with most SSH servers.
Especially given that multiple protocols have been called 'SFTP'.
> Supported decorators:
Perhaps "prefixes" would be a better term.
> --------------------------
> * Decorator: chroot+
> A decorator that can convert any transport to be chrooted.
>
> This is requested via the 'chrooted+' prefix to get_transport().
>
>
> * Decorator: readonly+
> A decorator that can convert any transport to be readonly.
>
> This is requested via the 'readonly+' prefix to get_transport().
> +# insert here the transports which haven't to be displayed
"haven't to" => "should not"
> + transport_dict={}
> + out=[]
> + for proto, factory_list in _protocol_handlers.iteritems():
> + if proto == None:
> + proto = "<default>"
I think None should be skipped.
> + for f in factory_list:
> + try:
> + if f.__module__ == "bzrlib.transport":
> + # this is a lazy load transport, because no real ones
> + # are directlry in bzrlib.transport
> + mod = __import__(f.module, globals(), locals(), [f.classname])
> + klass = getattr(mod, f.classname)
> + else:
> + klass = f.__module__
> +
> + if hasattr(klass, "help_txt"):
> + doc = klass.help_txt
> + else:
> + doc = klass.__doc__
This is a very ugly approach. We already have registries, which are a
much cleaner approach, so I think it would make sense to change
_supported_protocols into a Registry subclass.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFrr3f0F+nu1YWqI0RAtnlAJ9qQ4xfXNLKay0J2d8YFS2x8XkHVQCeOLwx
/iMsXHU7IAFmHSS0O2+l31U=
=OSc9
-----END PGP SIGNATURE-----
More information about the bazaar
mailing list