[RFC] Trying to get something better that revno:N:branch to deal with remote revs

[John Arbash Meinel]

Matthieu Moy wrote:
> John Arbash Meinel <john at arbash-meinel.com> writes:
> 
>> Well, there are two things at work here, Firefox and HTTP. This does work:
>> http://bzr.arbash-meinel.com/foo;bar
>> But if you go to here:
>> http://bzr.arbash-meinel.com/
>> And click on the link, you get:
>> http://bzr.arbash-meinel.com/foo%3bbar
> 
> Yes, but that's cheating. The conversion happens in your Apache
> directory listing.
> 
> If you get here http://www-verimag.imag.fr/~moy/tmp/link.html and
> click the link, you'll get a ; in the URL.
> 
> IIRC, URL can be either in encoded form or in non-encoded form. In any
> case, at the HTTP level, it's the encoded form. For example, GNU Arch
> allowed only the non-encoded form on the command-line.
> 
> Indeed, as soon as you allow a mix, you've got some ambiguities,
> because 'http://bzr.arbash-meinel.com/foo%3bbar' is valid both in
> encoded and non-encoded form. But since everybody is already doing
> like this, I have no real objection.
> 
> There's still a problem with locations which are not URL. I'd rather
> avoid introducing this %3b encoding in actual filenames. One solution
> is to say that this case is rare enough to allow forcing people to use
> URLs instead.


The current bzr.dev code already has some functionality for the
differences between urls and unicode paths. Partially because if we want
to support unicode paths, it would really suck to always have to type
them a url escaped paths.

So right now we have: 'bzrlib.urlutils.normalize_url()' which is meant
as a command line helper.
As in, take a string that the argument parser creates, and turn it into
a valid 7-bit url.
It starts by looking for a protocol (foo://) and if it doesn't find it,
it uses local path conversions, instead of unicode-url conversions.

Yes, it is a little DWIM, but I think the balance ended up being useful.
Basically, for local paths, we assume that they have no url escaping
already. And escape all characters (which lets you access ~/%2C-foo)
This also turns relative paths into absolute paths, because we only
support absolute URLs at this level.

Now, if someone has to pass in something funky, they can use 'file:///'
syntax, which expects the path to be exactly a url.

In these cases we do not escape the URL control characters:
	';?:@&=+$,%#'

Which all have special meaning in URLs.

So my basic feeling is to make ';' special, and then have
'local_path_to_url' type functions not escape it. And have it processed
at a higher level.

Then if someone needs a local path which has a ';' in it, then they can
use the 'file:///full/path/with%3bsemicolon' syntax.

It isn't necessarily ideal, but I don't think it is ambiguous.

...

> 
> I have one more question or point against URL;spec (I'm not opposed to
> it, just not 100% convinced yet).
> 
> What meaning should be given to
> 
> $ bzr diff -r 4 ./branch1;revno:10
> 
> 1) it's an error

maybe

> 
> 2) it's bzr diff ./;revno:4 ./branch1;revno:10

You never specified '.', so this doesn't seem right to me.

> 
> 3) other ?

At best, it could mean 'bzr diff ./branch1;revno:4', which right now
means diff the working tree at ./branch1 against revno 4 of the same tree.

(Just try: bzr diff -r4 ./branch1)

> 
> 
> I'm sure we can find a case-by-case semantics for this case of thing,
> but I don't want the specification to be made of a set of nested if
> statements (diff's interface is already pretty complex to define since
> the same argument can be a file, a branch location or a tree
> location).
> 
> Maybe the rule could be "It's forbidden to mix -r and URL;spec in a
> command line". Indeed, URL;spec would be strictly more expressive than
> -r, since "-r X..Y" can be rewritten "./;X ./;Y" while the opposite is
> not true.
> 

I would tend to go with the 'forbidden to mix'. There are some
complications that arise through all of this, though. So we would need a
general consensus before I would recommend changing things.

One thing I think having revisions specs in URLs is that we need to
change the command parsing so that you could specify a given argument is
a URL + revisionspec (potentially).
Then converting from a path to objects would happen at a higher level,
making it more convenient for Command classes.

At least, that would be a thought.

John
=:->

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