Implementation Details about Changesets Evolution

This page is intended for developer

For a user perspective have a look at the ChangesetEvolution page

Changesets evolution allows for safe rewriting of Mercurial history. This has a close relationship with Phases

• Presentation of the concept: http://hg-lab.logilab.org/doc/mutable-history/html/

  Related experimental extension (usable): http://bitbucket.org/marmoute/mutable-history/overview

1. Core principle

• Store an explicit obsolescence marker between new and old version of rewritten changeset.
• This marker is *not* part of the changeset (should not alter the hash).
• People are able to collaborate on evolving changeset

2. Additional ideas

• Store final delta in a real and autonomous changeset.
• The Obsolescence markers are exchangeable without rewritten changeset.
• Easily allow other extension to manipulate such relation (and to hook on such operation)

3. Handled situations

• Rewriting content of a changeset
• Deleting/killing a changeset
• Splitting a single changeset into multiple ones
• Collapsing/folding multiple changeset into a single one
• Changing changeset order
• Adding (e.g., pulling) a changeset evolution that conflicts with another one
• Adding (or adding in general) new changesets on one which already evolved (or evolving a changeset that have descendants)

4. Changeset Obsolescence

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 phases for details).

Obsolescence is tracked using "obsolescence markers", a piece of metadata that tracks 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.