mutable-history / docs / obs-implementation.rst

Full commit

Implementation of Obsolete Marker


This document is still in heavy work in progress

Main questions about Obsolete Marker Implementation

How shall we exchange Marker over the Wire ?

We can have a lot of markers. We do not want to exchange data for the one we already know. Listkey() is not very appropriate there as you get everything.

Moreover, we might want to only hear about Marker that impact changeset we are pulling.

pushkey is not batchable yet (could be fixed)

A dedicated discovery and exchange protocol seems mandatory here.

Various technical details

Some stuff that worse to note. some may deserve their own section later.

storing old changeset

The new general delta format allows a very efficient storage of two very similar changesets. Storing obsolete children using general delta takes no more place than storing the obsolete diff. Reverted file will even we reused. The whole operation will take much less space the strip backup.

Abstraction from history rewriting UI

How Mercurial handles obsolete marker is independent from what decides to create them and what actual operation solves the error case. Any of the existing history rewriting UI (rebase, mq, histedit) can lay obsolete markers and resolve situation created by others. To go further, a hook system of obsolete marker creation would allow each mechanism to collaborate with other though a standard and central mechanism.

Obsolete marker storage

The Obsolete marker will most likely be stored outside standard history. They are multiple reasons for this:

First, obsolete markers are really perpendicular to standard history there is no strong reason to include it here other than convenience.

Second, storing obsolete marker inside standard history means:

  • A changeset must be created every time an obsolete relation is added. Very inconvenient for delete operation.
  • Obsolete marker must be forged at the creation of the new changeset. This is very inconvenient for split operation. And in general it becomes complicated to fix history afterward in particular when working with older clients.

Storing obsolete marker outside history have several pros:

  • It eases Exchange of obsolete markers without unnecessary obsolete changeset contents.
  • It allows tuning the actual storage and protocol exchange while maintaining compatibility with older clients through the wire (as we do the repository format).
  • It eases the exchange of obsolete related information during discovery to exchange obsolete changeset relevant to conflict resolution. Exchanging such information deserves a dedicated protocol.


Extinct changeset and obsolete marker will most likely be garbage collected as some point. However, archive server may decide to keep them forever in order to keep a fully auditable history in its finest conception.

Current status

Obsolete marker are partialy in core.


  • storage over obsolete marker
  • exchange suing pushkey
  • extinct changeset are properly hidden
  • extinct changeset are excluded from exchange