This repository holds three experimental extensions that introduce concepts

related to history rewriting in mercurial.

    Introduce a state concept. It allows to track which changesets have been

    made public and immutable and which you want to keep local.

    Introduce an ``obsolete`` concept that tracks new versions of rewritten

    changesets.

    A collection of commands to rewrite the mutable part of the history.

================

This extension adds the state concept. A changeset now has one of the following

*states*:

    Changesets in the ``published`` state are the core of the history.  They are

    changesets that you published to the world. People can expect them to always

    exist. They are changesets as you know them. **By default all changesets

    * They are exchanged with other repositories (included in pull//push).

    * They are not mutable, extensions rewriting history should refuse to

    Changesets in the ``ready`` state have not yet been accepted in the

    immutable history. You can share them with others for review, testing or

    published history (and become immutable) or be rewritten and never make it

    to the published history.

    * They are exchanged with other repositories (included in pull//push).

    * They are mutable, extensions rewriting history accept to work on them.

    Changesets in the ``draft`` state are heavy work in progress you are not

    yet willing to share with others.

    * They are not exchanged with other repositories. pull//push do not see them.

    * They are mutable, extensions rewriting history accept to work on them.

States of changesets have to be consistent with each other. A ``published``

have ``published`` or ``ready`` ancestors.

By default all changesets in the repository are ``published``. Other states must

be explicitly activated. When a state is not activated, changesets in this state

are handled as changesets of the state before it (``draft`` are handled as

``ready``, ``ready`` are handled as ``published``).

Changesets will automatically move to ``published`` state when:

* pushed to a repo that doesn't support the ``ready`` state.

The extension adds a ``hg states`` command to choose which states are used by a

A command is also added for each active state. The command has the name of the

state and is used to manually change the state of a changeset. This is mainly

useful to move changesets from ``draft`` to ``ready``.:: 

A new template keyword ``{state}`` has been added.

We add new ``readyheads()`` and ``publishedheads()`` revset directives. This

returns the heads of each state **as if all of them were activated**.

Why to you store activate state outside ``.hg/hgrc``?

.....................................................

``.hg/hgrc`` might be ignored for trust reason. we don't want the # XXX

Why is the ``dead`` state missing?

.....................................................

1. The ``dead`` state has a different behaviour that requires more work to be

implemented.

2. I believe that the use cases of ``dead changeset`` are better covered by the

* Moving boundary backward (code exists in the ``liquid`` extension done at the

* support for default value in configuration (for init and clone)

* stronger pull//push support (unknown remote heads confuse the current code)

* display the number of changesets that change state when activating a state.

* have a switch to select if changesets do change state on state activation.

This extension introduces the *obsolete* concept. It adds a new *obsolete*

relation between two changesets. A relation ``<changeset B> obsolete <changeset

A>`` is set to denote that ``<changeset B>`` is new version of ``<changeset

A>``.

changeset history. Standard changeset history versions files. The *obsolete*

relation versions changesets.

obsolete changesets are hidden.

a ``debugobsolete`` command has been added.

* refuse to obsolete published changesets