Mercurial 2.3 obsolescence markers: a mixed-client compatibility decision

Direct answers

1. Restrict evolve to modern clones. Do not enable it for the shared repository by configuration alone. Allow history rewriting only on clones confirmed to run Mercurial 2.3 or later with evolve installed and enabled.
2. Protect public changesets. Do not mark a public changeset obsolete while it remains public. Mercurial refuses this until the changeset returns to draft or secret. Coordinate any phase change with consumers who already pulled the changeset.
3. Require a pre-2.3 pull/push test. Create and obsolete a changeset on a modern evolve client, push it to a pre-2.3 destination, pull it back, and confirm obsolescence markers are neither stored nor resurrected by the older client.

Likely explanation versus confirmed facts

Likely explanation: Mercurial 2.3 introduced persistent obsolescence markers, and evolve is an optional client-side extension, not enabled by default. A repository cannot force every clone to use it, so clients older than 2.3 can pull changeset content but are not expected to preserve markers. They may also push obsolete changesets back into the repository without understanding the marker.

Confirmed facts for planning only: evolve packaging varies by distribution, and the 2.3 boundary is assumed applicable in this scenario. Current documentation and release-specific behavior should be verified before changing shared configuration. Absence of errors from an older client is not evidence that markers survived.

Steps for this case

1. Inventory the oldest Mercurial version among all clones that will pull or push the rewritten history.
2. Confirm evolve is installed and enabled on every modern clone that will perform or consume rewriting.
3. Isolate rewriting to a private or scratch repository if any clone runs older than 2.3 or lacks evolve.
4. Before rewriting any changeset already published publicly, change its phase to draft or secret only after coordinating with downstream consumers.
5. Run the interoperability test below before enabling the policy on the shared repository.

Interoperability test for marker survival

1. Provision one modern clone (Mercurial >=2.3, evolve enabled) and one pre-2.3 clone.
2. From the modern clone, create a changeset, mark it obsolete with a replacement, and push to the pre-2.3 destination.
3. Pull from the pre-2.3 destination back to the modern clone.
4. Inspect obsolescence markers before and after the pre-2.3 client touches the repository.
5. Accept only if the pre-2.3 client neither stores nor resurrects markers and the modern clone still recognizes the replacement.

If a pre-2.3 binary is unavailable, do not claim interoperability. Mark the older-client path as unverified and restrict rewriting to modern clones.

Safe verification commands

hg --version
hg debugconfig extensions.evolve
hg phases --verbose
hg log --template '{node|short} {phase} {obsolete}'

These read-only commands confirm client version, whether evolve is active, changeset phase, and marker presence. Run them on a scratch clone.

Missing diagnostic

What is the oldest Mercurial version among clones that will pull or push this history, and is evolve installed and enabled on every one of them? This detail determines whether you can safely permit rewriting or must restrict it to a private repository.

Assumption: the Mercurial 2.3 compatibility boundary remains applicable. Uncertainty: current documentation and release-specific evolve packaging have not been independently verified; treat this as a draft for human review before changing shared configuration.