Mercurial Evolve Extension and Shared Repository Obsolescence Markers

Answer

To accept and store obsolescence markers on a shared/public repository the server process must have the evolve extension loaded. With evolve enabled the server negotiates the obsmarkers wire protocol and writes markers to the repository obsstore. Without it, pushes that include markers are rejected or markers are dropped.

For collaborators without evolve enabled, changesets are still transferred normally because they are core Mercurial data. Obsolescence markers are optional metadata. Clients without evolve do not request, store or interpret markers, so they see both the original and replacement commits as normal history with no indication of obsolescence.

Confirmed facts

• Server side: evolve must be loaded in the server hgrc, e.g. [extensions] evolve =. No separate Mercurial permission flag is required for markers beyond normal push access.
• Markers are stored as repository metadata alongside changesets, typically in .hg/store/obsstore. The server must allow writes to that location and run a Mercurial version with stable evolve support, commonly 4.8+.
• Clients without evolve still receive changesets on push/pull. They do not request or store markers, so hg debugobs is unavailable and hg log shows both obsolete and replacement commits without filtering.

Likely explanation

Marker synchronization is extension-dependent and best-effort. A client without evolve will not propagate markers it never received, and a push from such a client cannot create markers. In mixed teams evolve-enabled clones filter/hide obsolete commits while non-evolve clones show all commits. Client-side evolve settings such as evolve.allowpushnewheads control what the client is allowed to push, not server acceptance of markers.

Steps needed for this case

1. Enable evolve on the server process. In the server .hgrc or the system hgrc used by hgweb/hg serve:

   [extensions]
   evolve =

2. Confirm the extension is loaded and the repository is writable by the push user:

   hg --config extensions.evolve= debugconfig extensions.evolve
   hg --cwd /path/to/repo debugconfig

   Check that .hg/store/obsstore exists and is writable after a push.
3. Verify marker propagation with evolve enabled on both sides:

   hg debugobs

   Run on local clone and on a clone of the public repo after push/pull. Successor/predecessor pairs should match.
4. Do not rely on server evolve enablement alone for policy. Add push hooks if you need to restrict who can rewrite public history.

Verification note: On a clone without evolve, hg debugobs is unavailable and log shows both obsolete and replacement commits.

One missing diagnostic detail that changes the recommendation: what Mercurial version is running on the server and how is the repository served, e.g., hgweb under Apache, hg serve, or SSH? Version families and the serving method affect where the server hgrc is read and whether obsstore writes are permitted.