D2057: rust implementation of hg status

[indygreg (Gregory Szorc)]

indygreg added a comment.


  In https://phab.mercurial-scm.org/D2057#43989, @durin42 wrote:
  
  > In https://phab.mercurial-scm.org/D2057#43988, @kevincox wrote:
  >
  > > In https://phab.mercurial-scm.org/D2057#43987, @durin42 wrote:
  > >
  > > > Mercurial tries to be principled about always treating filenames as bytes. AIUI https://www.mercurial-scm.org/wiki/WindowsUTF8Plan is still the plan of record there?
  > >
  > >
  > > Reading that page it seems to claim that filenames should be utf8, not bytes. If utf8, this is what the code does, but if it is bytes that definitely won't work.
  >
  >
  > IIRC it's bytes everyplace except Windows, where we pretend utf8 is real?
  >
  > We may have to make adjustments to this plan on macOS with APFS, but I'm not sure about that yet.
  
  
  I think we want to express a path as a dedicated type which has different underlying storage depending on the platform (bytes on Linux, UTF-16 on Windows). All filesystem operations should take a `Path` instance to operate on. This is the only way to cleanly round trip filenames between the OS, the application, and back to the OS. That leaves us with the hard problem of normalizing Mercurial's storage representation of paths (bytes) with the operating system's. But this world is strictly better than today, where we lose path data from the OS because we use POSIX APIs.
  
  FWIW, Python 3 rewrote the I/O layer to use Win32 APIs everywhere. Combined with the `pathlib` types, I'm pretty sure Python 3 can round trip paths on Windows. I also think Rust's path type(s) have OS-dependent functionality.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D2057

To: Ivzhh, #hg-reviewers, kevincox
Cc: glandium, krbullock, indygreg, durin42, kevincox, mercurial-devel