D8039: chg: force-set LC_CTYPE on server start to actual value from the environment

yuja (Yuya Nishihara) phabricator at mercurial-scm.org
Thu Jan 30 12:02:46 EST 2020


yuja added a comment.


  >   What do you think about this approach:
  >   1. The server detects that LC_TYPE is coerced.
  >   2. When handling the "validate" command, the server sends back "invalidate this server, and fallback to original hg" response.
  >   This makes chg/non-chg behave consistently with some startup overhead in mis-configured environment. The chg client can potentially print a warning to remind the user to fix their environment.
  
  That could be, but if we do want to make chg/hg behavior consistent, maybe we
  can adjust the hash computation logic?
  
  1. client sends CHG_ORIG_LC_CTYPE or CHG_UNSET_LC_CTYPE when spawning server
  2. they're kept in environ dict, but override LC_CTYPE while computing hash, and excluded from the hash
  3. client does not send these variables over setenv command, but passes the validation because `{CHG_ORIG_LC_CTYPE: x, LC_CTYPE: y} == {LC_CTYPE: x}`.
  
  If we had a sha1 logic in C, we could compute the env hash at client side.
  Python 3 can't be trusted.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D8039/new/

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

To: spectral, #hg-reviewers
Cc: quark, yuja, mjpieters, mercurial-devel


More information about the Mercurial-devel mailing list