Mercurial 2.3 obsolescence markers: a mixed-client compatibility decision

Compatibility decision

A shared repository is being considered for history rewriting with Mercurial’s optional evolve extension. The goal is to choose an obsolescence policy that does not silently lose rewrite metadata when clones run different Mercurial releases.

Mercurial 2.3 introduced persistent obsolescence markers. Clients older than that boundary may not preserve those markers during pull, while obsolete changesets also interact with push acceptance and the public, draft, and secret phases. A public changeset cannot become obsolete until it returns to a non-public phase. The evolve extension is not enabled by default, and its packaging may vary by distribution.

Assume the 2.3 compatibility boundary remains applicable, but confirm current documentation and release-specific behavior before changing the shared configuration.

• Should evolve be enabled in a mixed-version repository, or restricted to clones known to support obsolescence metadata?
• Which phase policy should govern rewriting changesets already published publicly?
• What interoperability test should be required for marker survival after pull and push, including a destination older than 2.3?