annotate README @ 34:f28116682827

Add a few information about obsolete relation.

=============================
Mutable History For Mercurial
=============================

This repository hold several experimental extension that introduce concept
related to history rewriting in mercurial. You will find three different
extensions.

:states:

    Introduce a state concept. It allow to track which changeset have been make
    public and immutable and which you want to keep local.

:obsolete:

    Introduce an obsolete concept that track new version of rewritten changeset.

:rewrite:
    A collection of command to rewrite the mutable part of the history.



**These extensions are experimental and are not meant for production.**


States Extension
======================

state: experimentally functional

(see http://mercurial.selenic.com/wiki/StatesPlan)

This extension the state concept. A changeset now have one of the following *state*:

:published:

    Changeset in the ``published`` state are the core of the history.  They are
    changeset that you published to the world. People can expect them to always
    be exist. This is changeset as you know them. **By default all changeset
    are published**

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

    * They are not mutable, extension rewriting history should refuse to
      rewrite them.

:ready:

    Changeset in the ``ready`` state have not been accepted in the immutable
    history yet. You can share them with other for review, testing or
    improvement. Any ``ready`` changeset can either be included in the
    published history (and become immutable) or be rewritten and rever make it
    the published history.

    * They are exchanged with other repository (included in pull//push).
    * They are mutable, extension rewriting history accept to work on them.

:draft:

    Changeset in the ``draft`` state are heavy work in progress you are
    currently working on without willing to share with other.

    * They are not exchanged with other repository. pull//push does not see them.
    * They are mutable, extension rewriting history accept to work on them.


State of changeset have to be consistent with each other. A ``published``
changeset can only have ``published`` ancestors. A ``ready`` changeset can only
have ``published`` or ready ancestor.


Usage and Feature
------------------

By default all changeset in the repository are ``published``. Other state must
be explicitly activated. When a state is not activated, changeset of this state
are handled as changeset of the state before him. (``draft`` are handled as
``ready``, ``ready`` are handled as ``published``)

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

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

* Tagged by a non local tag.

Commands
........

The extension add and ``hg states`` command to choose which state are used by a
repository, see ``hg help states for details``.

A command is also added for all active states. The command have the name of the
states and is used to manually change the state of a changeset. This is mainly
usefull to move changeset from ``draft`` to ``ready``.:: 

    hg ready tip

Template
........

A new template keyword ``{state}`` have been added

Revset
........

We add a new ``readyheads()`` and ``publishedheads()`` revset directive. This return the heads of each states **as if all of them was activated**.

FAQ
---

Why to you store activate state ouside ``.hg/hgrc``
....................................................

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

Why is the ``dead`` state missing
....................................................

1. The ``dead`` state have a different behaviour that require more work to be
implemented

2. I believe that the usecase of ``dead changeset`` are better covered by the
``obsolete`` extension.

To Do
-----

* Moving boundary backward (code existist in ``liquid`` extension done at the
  CPH sprint)

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

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

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

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

* proper revset directive.




Obsolete Extension
======================

state: in progress

This extension introduce the *obsolete* concept. It adds a new *obsolete* relation between two changeset. A relation ``<changeset B> obsolete <changeset A>`` is set to denote that ``<changeset B>`` is new version of ``<changeset A>``

The *obsolete* relation act as a **perpendicular history** to the standard
changeset history. Standard changeset history versions files. When *obsolete*
relation versions changeset

Usage and Feature
------------------

obsolete changeset are hidden.

Commands
........


a ``debugobsolete`` command have been added.


To Do
-----

* do not exchange them

* handle non-obsolete children

* exchange the obsolete information

* refuse to obsolete published changeset

* handle split

* handle conflict

* handle out of sync

rewrite Extension
======================

state: To be written