view tests/test-status-eacces.t @ 51815:460e80488cf0

typing: lock in correct changes from pytype 2023.04.11 -> 2023.06.16 There were a handful of other changes to the pyi files generated when updating pytype locally (and jumping from python 3.8.0 to python 3.10.11), but they were not as clear (e.g. the embedded type in a list changing from `nothing` to `Any` or similar). These looked obviously correct, and agreed with PyCharm's thoughts on the signatures. Oddly, even though pytype starting inferring `obsutil._getfilteredreason()` as returning bytes, it (correctly) complained about the None path when it was typed that way. Instead, raise a ProgrammingError if an unhandled fate is calculated. (Currently, all possibilities are handled, so this isn't reachable unless another fate is added in the future.)
author Matt Harbison <matt_harbison@yahoo.com>
date Tue, 20 Aug 2024 18:30:47 -0400
parents 86d2a28c018e
children fdb1971bf634
line wrap: on
line source

#testcases dirstate-v1 dirstate-v2

#if dirstate-v2
  $ cat >> $HGRCPATH << EOF
  > [format]
  > use-dirstate-v2=1
  > [storage]
  > dirstate-v2.slow-path=allow
  > EOF
#endif


The proliferation of status implementations can be confusing:
- The pure python implementation:
(no-rhg pure !)
- The C implementation:
(no-rhg no-rust no-pure !)
- The two rust implementations:
(rhg !)
(no-rhg rust !)

  $ hg init repo1
  $ cd repo1
  $ mkdir d1
  $ touch d1/x
  $ hg commit -Am.
  adding d1/x
  $ touch d1/y
  $ chmod -r d1
  $ hg status
  d1: $EACCES$
  ! d1/x (rhg !)
  ! d1/x (no-rhg rust !)
  $ hg status
  d1: $EACCES$
  ! d1/x (rust !)
  ! d1/x (no-rust rhg !)
  $ chmod +r d1
  $ hg status
  ? d1/y

  $ touch d1/z
  $ hg status
  ? d1/y
  ? d1/z