##// END OF EJS Templates
typing: add type hints to the `charencode` module...
typing: add type hints to the `charencode` module Since this module is dynamically imported from either `mercurial.pure` or `mercurial.cext`, these hints aren't detected in `mercurial.encoding`, and need to be imported directly there during the type-checking phase. This keeps the runtime selection via the policy config in place, but allows pytype to see these as functions with proper signatures instead of just `Any`. We don't attempt to import the `mercurial.cext` version yet because there's no types stubs for that module, but this will get the ball rolling. I thought this would spill over into other modules from there, but the only two *.pyi files that changed were for `encoding` and `charencode`. Applying this to other dynamically selected modules will clean some things up in other files, so this is a start. I had originally redefined the functions in the type-checking block (like some of the `os.path` aliasing in `mercurial.util`), but this is better because we won't have another duplication of the definitions that may get out of date.

File last commit:

r47781:da4e6d7a default
r52615:43adbe03 default
Show More
evolution.txt
56 lines | 2.1 KiB | text/plain | TextLexer
Obsolescence markers make it possible to mark changesets that have been
deleted or superseded in a new version of the changeset.
Unlike the previous way of handling such changes, by stripping the old
changesets from the repository, obsolescence markers can be propagated
between repositories. This allows for a safe and simple way of exchanging
mutable history and altering it after the fact. Changeset phases are
respected, such that only draft and secret changesets can be altered (see
:hg:`help phases` for details).
Obsolescence is tracked using "obsolescence markers", a piece of metadata
tracking which changesets have been made obsolete, potential successors for
a given changeset, the moment the changeset was marked as obsolete, and the
user who performed the rewriting operation. The markers are stored
separately from standard changeset data can be exchanged without any of the
precursor changesets, preventing unnecessary exchange of obsolescence data.
The complete set of obsolescence markers describes a history of changeset
modifications that is orthogonal to the repository history of file
modifications. This changeset history allows for detection and automatic
resolution of edge cases arising from multiple users rewriting the same part
of history concurrently.
Current feature status
======================
This feature is still in development.
Instability
===========
Rewriting changesets might introduce instability.
There are two main kinds of instability: orphaning and diverging.
Orphans are changesets left behind when their ancestors are rewritten.
Divergence has two variants:
* Content-divergence occurs when independent rewrites of the same changesets
lead to different results.
* Phase-divergence occurs when the old (obsolete) version of a changeset
becomes public.
It is possible to prevent local creation of orphans by using the following config::
[experimental]
evolution.createmarkers = true
evolution.exchange = true
You can also enable that option explicitly::
[experimental]
evolution.createmarkers = true
evolution.exchange = true
evolution.allowunstable = true