This instance will be upgraded to Heptapod 0.26.0rc1 on 2021-10-26 at 14:30 UTC+2 (a few minutes of down time)

Commit 4c2c363e authored by Pierre-Yves David's avatar Pierre-Yves David
Browse files

Add some doc.

parent c27491be4431
=============================
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
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
......@@ -123,7 +123,16 @@ def showstate(ctx, **args):
def cmdstates(ui, repo, *states, **opt):
"""show enabled states"""
"""view and modify activated states.
With no argument, list activated state.
With argument, activate the state in argument.
With argument plus the --off switch, deactivate the state in argument.
note: published state are alway activated."""
if not states:
for st in sorted(repo._enabledstates):
ui.write('%s\n' % st)
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment