Non-Working Mercurial after Mac OS X Lion (10.7) Install

[Mads Kiilerich]

On 08/22/2011 02:38 PM, Paul Boddie wrote:
> On 22/08/11 14:28, Mads Kiilerich wrote:
>>
>> Yes, this path should be written as
>> file:///Volumes/Colossus_5/Library/WebServer .
>>
>> That is however not fully consistent with other schemes (especially
>> ssh), so in principle it should be
>> file:////Volumes/Colossus_5/Library/WebServer because it is an absolute
>> path.
>
> I think that would violate the specification:
>
> http://tools.ietf.org/html/rfc3986#section-3.3
>
> See the description of "path-absolute" and the comment in the "path" rule.

Yes, Mercurials url concept might not be fully RFC compliant - that 
shows especially in ssh urls with absolute paths which might look like 
network-paths.

It would IMHO be reasonable to expect that Mercurials file paths are 
handled similar to ssh paths. It is however also reasonable to expect 
that "RFC-compliant" file urls work. It is less reasonable to expect 
that other non-standard file-like urls that work in other places also 
work in Mercurial.

(The URL grammar in the RFC do not the match the usual semantics of http 
URLs. http://foo/bar do usually not point at the absolute path /bar but 
the relative path bar relative to documentroot, just like 
http://foo/~bar usually is interpreted as ~bar (which is expanded) and 
not as /~bar. Mercurial tend to prefer consistency with that over strict 
RFC compliance. The same problem from another point of view is that it 
is unclear/unrealistic how relative file paths should be represented in 
strict RFC URLs.)

(FWAWIW (for what a wiki is worth?) 
http://en.wikipedia.org/wiki/File_URI_scheme says "The single slash 
between host and path is part of the syntax of file URLs" - that is also 
Mercurials preferred interpretation. That is consistent with the 
"file:///c|/WINDOWS/clock.avi" example but not with "file:///etc/fstab" 
... unless it is assumed that relative paths are relative to root and 
thus absolute ...)

So: URL handling is a mess and it could be argued that Mercurials 
attempt at making it more consistent has made it more messy and 
inconsistent. Mercurials new URL handler has revealed a lot of problems 
and undefined behaviour but will at least make it possible to handle 
URLs in a consistent way in Mercurial.

(Another known issue with the URL handler is the one described in 
http://wingolog.org/archives/2010/12/23/doing-it-wrong )

/Mads