[PATCH 11 of 11 RFC] url: refactor util.drop_scheme() and hg.localpath() into url.localpath()

[Brodie Rao]

On Tue, Mar 29, 2011 at 5:23 AM, Mads Kiilerich <mads at kiilerich.com> wrote:
> On 03/29/2011 03:11 AM, Brodie Rao wrote:
>>
>> On Sun, Mar 27, 2011 at 3:34 PM, Mads Kiilerich<mads at kiilerich.com>
>>  wrote:
>>>>
>>>> Comparison of old and new behaviors:
>>>>
>>>> URL                      drop_scheme()   hg.localpath()
>>>>  url.localpath()
>>>> ===                      =============   ==============
>>>>  ===============
>>>> file://foo/foo           /foo            foo/foo           /foo
>>>> file://localhost:80/foo  /foo            localhost:80/foo  /foo
>>>> file://localhost:/foo    /foo            localhost:/foo    /foo
>>>> file://localhost/foo     /foo            /foo              /foo
>>>> file:///foo              /foo            /foo              /foo
>>>> file://foo               (empty string)  foo               /
>>>> file:/foo                /foo            /foo              /foo
>>>> file:foo                 foo             foo               foo
>>>> /foo                     /foo            /foo              /foo
>>>> file:///C:/foo           /C:/foo         /C:/foo           /C:/foo
>>>> file://C:/foo            /foo            C:/foo            /foo
>>>> file://D:/foo            /foo            D:/foo            /foo
>>>
>>> Do we really want to silently accept and ignore any 'host' specification
>>> and
>>> thus also ignore 'drive letters'? Wouldn't it be better to abort if the
>>> host
>>> is something it shouldn't be, and thus only accept '' and 'localhost' -
>>> and
>>> driveletters on windows?
>>
>> I thought about raising abort, but both Chrome and Firefox silently
>> interpret hostnames in file:// URLs as localhost.
>
> I think it makes a difference that they are browsers that can give visual
> feedback - and will search and guess if the url specified by the user
> doesn't work.
>
> Mercurial should expect the user to specify the urls correctly. If the user
> makes an error we should tell him to fix it, not guess what he means.
>
> (It seems like the friendly but incorrect and inconsistent interpretation of
> file://foo/foo would be /foo/foo (or //foo/foo). But I would rather see an
> abort than that.)

OK, I can see the value in that. I'll create a patch for it.

>>>>  def has_scheme(path):
>>>>      return bool(url(path).scheme)
>>>
>>> btw: would it make sense here to normalize 'file' urls to be just their
>>> path
>>> and no scheme?
>>
>> I'm not sure what you mean. Isn't that what it does now? (Plus the
>> drive promotion stuff).
>
> We now have
>    >>> url('file:///home/joe/repo')
>    <url scheme: 'file', path: '/home/joe/repo'>
> it would perhaps be more consistent if it was
>    <url path: '/home/joe/repo'>
>
> - but that depends on how much and where you want to hardcode handling of
> the file (and bundle) schemes.

I don't see any benefit to silently discarding information (the scheme
that was used). file:// also works differently in that it interprets
percent-encoded characters.