[PATCH 1 of 8 RFC] vfs: replace invocation of file APIs of os module by ones via vfs

[Adrian Buehlmann]

On 2012-06-17 08:25, Matt Mackall wrote:
> On Sat, 2012-06-16 at 11:07 +0200, Adrian Buehlmann wrote:
>> Have you guys put some thought into how to deal with repo root paths
>> that contain "wide" characters already?
> 
> No, and in fact I'd rather not think about that now. This topic is
> already muddy/complex enough, so I've tried to carve off a solvable
> piece to tackle.

I think solving this one first might be better than ignoring it now and
having to deal with it later.

If we ignore that now, we are chosing solutions based on that "ignoring".

I think solving this one first would actually be easier now.

> Interestingly, of all the complaints we've had about Unicode on Windows,
> I'm pretty sure no one has ever mentioned having an issue being unable
> to run hg commands in a directory that can't be encoded in their
> system's ANSI code page. If I had to guess, that's because doing a
> mkdir/chdir into such a directory in the shell is non-trivial. Also, it
> just doesn't come up nearly as often as the "my umlaut doesn't look like
> an umlaut on UTF-8 systems" issue.

I think GUI tools like TortoiseHg, which don't operate on a command line
shell would have no problem exploring repositories at roots with funny
chars in the path, if the mercurial API would support it.

The whole Windows GUI is based on explorer-like tools. That's also why
people enter funny chars for their file and dirctory names in the first
place. They do that in explorer.

Also, you can start hg.exe with the CreateProcess API on Windows (which
has a CreateProcessW variant), which has a lpCurrentDirectory parameter,
and you can feed command line arguments using lpCommandLine parameter.
Is there a need for shell?

Now, we seem to be aiming for supporting funny chars in tracked files,
but we can't have funny chars in the path of the repo roo? That seems
odd to me.

>> Also interesting seem to be other paths, like config files or paths to
>> merge tools. Interesting paths can also originate from registry keys
>> (see 133a7922a900).
> 
> Similarly, that path has also worked for years under the assumption that
> paths are ANSI-decodable. The bug report arose when someone had
> something that wasn't _ASCII_-decodable, which no one noticed for a
> year.
> 
> http://bz.selenic.com/show_bug.cgi?id=3467
>