diff README @ 59:02fba620d139

move part of the readme about states in states itself.

--- a/README	Fri Sep 09 11:15:59 2011 +0200
+++ b/README	Fri Sep 09 15:56:50 2011 +0200
@@ -23,129 +23,7 @@
 **These extensions are experimental and are not meant for production.**
 
 
-States Extension
-================
-
-state: experimentally functional
-
-(see http://mercurial.selenic.com/wiki/StatesPlan)
-
-This extension adds the state concept. A changeset now has one of the following
-*states*:
-
-:published:
-
-    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
-    are published**
-
-    * They are exchanged with other repositories (included in pull//push).
-
-    * They are not mutable, extensions rewriting history should refuse to
-      rewrite them.
-
-:ready:
-
-    Changesets in the ``ready`` state have not yet been accepted in the
-    immutable history. You can share them with others for review, testing or
-    improvement. Any ``ready`` changeset can either be included in the
-    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.
-
-:draft:
-
-    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``
-changeset can only have ``published`` ancestors. A ``ready`` changeset can only
-have ``published`` or ``ready`` ancestors.
-
-
-Usage and Feature
-------------------
-
-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.
-
-* Tagged by a non local tag.
-
-Commands
-........
-
-The extension adds a ``hg states`` command to choose which states are used by a
-repository, see ``hg help states for details``.
-
-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``.:: 
-
-    hg ready tip
-
-Template
-........
-
-A new template keyword ``{state}`` has been added.
-
-Revset
-........
-
-We add new ``readyheads()`` and ``publishedheads()`` revset directives. This
-returns the heads of each state **as if all of them were activated**.
-
-FAQ
----
-
-Why to you store activate state outside ``.hg/hgrc``?
-.....................................................
-
-``.hg/hgrc`` might be ignored for trust reason. We don't want the trust issue
-to interfer with enabled state information.
-
-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
-``obsolete`` extension.
-
-To Do
------
-
-* be robust to unknown changeset in boundary
-
-* Moving boundary backward (code exists in the ``liquid`` extension done at the
-  CPH sprint)
-
-* 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.
-
-* proper revset directive.
-
-    - for changeset in states
-    - for "in use" changeset heads.
-
+See each extension documentation for details