[MERGE] (fixes #240910) Serve all filesystem roots on Windows

[Adrian Wilkins]

On Thu, Jun 19, 2008 at 12:00 AM, John Arbash Meinel
<john at arbash-meinel.com> wrote:
<snip>

> I'm pretty sure that "file://" is not really a valid URL, and it should
> be "file:///". (I believe that file:// is just a scheme).
>

'/' doesn't mean the same thing on Windows as *nix ; at best, it's
context-specific (root of current drive, but that should be '\' on
Windows, really).
If you take it in the spirit in which it's offered, _root_, there is no
real equivalent. It seemed consistent to use a URI with a null
path to identify a non-existent concept.

> Also it seems like this fails the "round trip" test. Specifically:
>
> from_url(to_url('/')) == ''
> to_url(from_url('file://')) ??? (Your check uses '/' to indicate it
> should be 'file://').
>

This is taking advantage of the implementation of LocalTransport
which just concats it's base path and relative path together.

It isn't meant to round-trip ; it's meant to escape from the drive trap
 * Resolving '/' to 'file://' captures the "not a real path on win32" idea
 * Resolving 'file://' back to '/' would send you back to "root of this drive"
 * Instead, we resolve it to an empty string, because it doesn't exist
 * LocalTransport can now cat '' and the URL path to get.. the URL path

In hindsight, I should have made it explicit in a comment that it's not meant
to round-trip.

Since there's no / on win32, it seems fair that LocalTransport on win32
should not use '/' as a base path, since it's meaning is at best ambiguous.
Empty string is the nearest equivalent, since all absolute paths must include
a drive letter or be a UNC path with at least a hostname.

As far as I can tell from code reading, the only place in
the code where you can create a LocalTransport with a base of
'/' on Windows is using ``bzr serve --directory=/`` ; everywhere
else is either implicitly using pwd, or a path from the shell (which cannot
be / on windows),
or passes through code that validates that it's appropriate for the
platform it's on. The use of '/' here is overlooked. Possibly the only
other place would be
the --directory options on commands like push and pull, but '/' as
an argument there would be ludicrous on both posix and windows.

> I would really like to merge something like this, but I don't think this
> is quite right.
>

It doesn't *feel* right, I agree, especially the asymmetric path conversion.
But it does work... and it doesn't seem to break things on Windows
(I'll do two selftest runs side-by-side tomorrow and confirm that).
(I can guarantee it doesn't break tests on posix :P  )
Given the schism between the two filesystem models, I think it's inevitable
that there is going to be a little discomfort. I think that any other
solution is
going to involve a great deal more code, and that feels worse than the little
discomfort of treating a path that doesn't exist on win32 as if it
doesn't exist.