##// END OF EJS Templates
repo: avoid copying/updating a dict on every `repo.__getitem__`...
repo: avoid copying/updating a dict on every `repo.__getitem__` This has some mild performance benefits. I'm looking into a pathological case where one of our `hg log` invocations takes several seconds, and according to hyperfine this reduces the wall time of the entire operation (running in chg) from: ``` Time (mean ± σ): 7.390 s ± 0.106 s [User: 7.058 s, System: 0.271 s] Range (min … max): 7.300 s … 7.625 s ``` to: ``` Time (mean ± σ): 7.046 s ± 0.091 s [User: 6.714 s, System: 0.279 s] Range (min … max): 6.916 s … 7.169 s ``` Note: the log command is slow due to an issue in our custom stuff executing `repo[<arg>]` 298,800 times. This performance improvement is likely not noticeable during normal operation, but I don't feel like it's making the code more difficult to understand, and every small bit helps. Differential Revision: https://phab.mercurial-scm.org/D9022

File last commit:

r44031:2e017696 default
r46036:4a0ccbec default
Show More
mergestate.txt
80 lines | 3.0 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
| * D: a file that the external merge driver will merge internally
| (experimental)
| * P: a path conflict (file vs directory)
| * m: the external merge driver defined for this merge plus its run state
| (experimental)
| * 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 driver run states (experimental):
| * u: driver-resolved files unmarked -- needs to be run next time we're
| about to resolve or commit
| * m: driver-resolved files marked -- only needs to be run before commit
| * s: success/skipped -- does not need to be run any more
Merge record states (indexed by filename):
| * u: unresolved conflict
| * r: resolved conflict
| * pu: unresolved path conflict (file conflicts with directory)
| * pr: resolved path conflict
| * d: driver-resolved 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.