##// END OF EJS Templates
typing: add some type hints for bundle2 capabilities...
typing: add some type hints for bundle2 capabilities Somewhere between hg 3dbc7b1ecaba and hg 8e3f6b5bf720, pytype determined the signature of `bundle20.capabilities` changed from `Dict[bytes, Tuple[bytes]]` to `Dict[bytes, Union[List[bytes], Tuple[bytes]]]`. First, I did try to simply be explicit about the previously inferred type, but it does seem to mix and match list/tuple now (e.g. in `writenewbundle()`). I tried changing the new list usage to tuple, but a couple of things complained, (and I think lists of one item are a little more clear to read anyway). So then I typed the dict value as `Sequence[bytes]`, which worked fine. But there's also a module level `capabilities` field, and when that's typed, pytype complains about `Sequence[bytes]` lacking `__add__`[1]. So I gave up, and just assigned it the type it wanted, with an alias. If somebody feels motivated to make the type consistent, it's simple enough to change the alias. The mutable default value to the constructor was removed to appease PyCharm's type checking on the field. (I didn't bother running the code through pytype prior to changing it, because we've previously made an effort to remove this pattern anyway.) I'm not sure why `getrepocaps()` has a default value for `role` that apparently raises an exception. It's just flagged for now so this series can land without risking additional problems. [1] https://foss.heptapod.net/mercurial/mercurial-devel/-/jobs/2466903

File last commit:

r46091:32ce4cba default
r52564:6fc31e7b default
Show More
mergestate.txt
68 lines | 2.5 KiB | text/plain | TextLexer
The active mergestate is stored in ``.hg/merge`` when a merge is triggered
by commands like ``hg merge``, ``hg rebase``, etc. until the merge is
completed or aborted to track the 3-way merge state of individual files.
The contents of the directory are:
Conflicting files
-----------------
The local version of the conflicting files are stored with their
filenames as the hash of their paths.
state
-----
This mergestate file record is used by hg version prior to 2.9.1
and contains less data than ``state2``. If there is no contradiction
with ``state2``, we can assume that both are written at the same time.
In this case, data from ``state2`` is used. Otherwise, we use ``state``.
We read/write both ``state`` and ``state2`` records to ensure backward
compatibility.
state2
------
This record stores a superset of data in ``state``, including new kinds
of records in the future.
Each record can contain arbitrary content and has an associated type. This
`type` should be a letter. If `type` is uppercase, the record is mandatory:
versions of Mercurial that don't support it should abort. If `type` is
lowercase, the record can be safely ignored.
Currently known records:
| * L: the node of the "local" part of the merge (hexified version)
| * O: the node of the "other" part of the merge (hexified version)
| * F: a file to be merged entry
| * C: a change/delete or delete/change conflict
| * P: a path conflict (file vs directory)
| * f: a (filename, dictionary) tuple of optional values for a given file
| * X: unsupported mandatory record type (used in tests)
| * x: unsupported advisory record type (used in tests)
| * l: the labels for the parts of the merge.
Merge record states (indexed by filename):
| * u: unresolved conflict
| * r: resolved conflict
| * pu: unresolved path conflict (file conflicts with directory)
| * pr: resolved path conflict
The resolve command transitions between 'u' and 'r' for conflicts and
'pu' and 'pr' for path conflicts.
This format is a list of arbitrary records of the form:
[type][length][content]
`type` is a single character, `length` is a 4 byte integer, and
`content` is an arbitrary byte sequence of length `length`.
Mercurial versions prior to 3.7 have a bug where if there are
unsupported mandatory merge records, attempting to clear out the merge
state with hg update --clean or similar aborts. The 't' record type
works around that by writing out what those versions treat as an
advisory record, but later versions interpret as special: the first
character is the 'real' record type and everything onwards is the data.