[MERGE] Add a 'nosmart+' transport decorator.

[Andrew Bennetts]

Stephen J. Turnbull wrote:
> Andrew Bennetts writes:
> 
>  > I'm not sure that "nosmart" is the best possible prefix for this, but "nobzr"
>  > somehow didn't feel right.  Comments welcome.
> 
> Since this is entirely a client-side behavior and requires no
> server-side changes, I think it should not be indicated by a new
> scheme, but rather by a command option.
> 
> As an aside, I don't know the history of this "transport decorator"
> stuff, but BCP 35 pretty clearly reserves this whole namespace to the
> IETF (ie, schemes containing no "-").  You need a standards-track RFC
> to define such a scheme.  Sure, this one is for internal use mainly by
> developers, but the separator would better be "-" to avoid any
> questions if such URIs should leak out into public documents and
> links.  That would apply to other such schemes, as well.

Well, we already have "bzr+ssh", for instance (and I don't see an RFC
for "svn+ssh"...).  That's not technically a decorator in bzrlib, but a
self-contained transport.  But the precedent for using "+" in documented
and intended-for-public-consumption URLs in bzr is already there.

Mainly our decorators are used for testing at the moment.  The currently
defined prefixes we have are: "readonly+", "fakenfs+", "trace+",
"unlistable+", "brokenrename+", and "vfat+".  It might be good for us to
rename all our decorators to be more conformant with BCP 35, by changing
the "+" to a "-" (although I'd be slightly sad to lose the mnemoic of "x
plus y").  I think such a change is out of scope for this patch though.

> In general, for the purpose of putting such protocol queries into the
> URL, I think it would be a better idea to use the query part of the
> URL.

I don't follow what you mean by this.  You mean something like
"http://host/path?smart=no"?

-Andrew.