# HG changeset patch # User Julien Cristau # Date 1312204305 -7200 # Node ID 0f98f87881bda04a533802696b696bd671d0ab95 # Parent f28116682827e4e67ffc04db9894849cce8033d3 Spelling fixes diff -r f28116682827 -r 0f98f87881bd README --- a/README Mon Aug 01 14:28:38 2011 +0200 +++ b/README Mon Aug 01 15:11:45 2011 +0200 @@ -2,21 +2,21 @@ 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. +This repository holds three experimental extensions that introduce concepts +related to history rewriting in mercurial. :states: - Introduce a state concept. It allow to track which changeset have been make - public and immutable and which you want to keep local. + Introduce a state concept. It allows to track which changesets have been + made public and immutable and which you want to keep local. :obsolete: - Introduce an obsolete concept that track new version of rewritten changeset. + Introduce an ``obsolete`` concept that tracks new versions of rewritten + changesets. :rewrite: - A collection of command to rewrite the mutable part of the history. + A collection of commands to rewrite the mutable part of the history. @@ -24,117 +24,119 @@ 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*: +This extension adds the state concept. A changeset now has one of the following +*states*: :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 + 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 repository (included in pull//push). + * They are exchanged with other repositories (included in pull//push). - * They are not mutable, extension rewriting history should refuse to + * They are not mutable, extensions 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 + 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 rever make it - the published history. + published history (and become immutable) or be rewritten and never make it + to the published history. - * They are exchanged with other repository (included in pull//push). - * They are mutable, extension rewriting history accept to work on them. + * They are exchanged with other repositories (included in pull//push). + * They are mutable, extensions 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. + 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 repository. pull//push does not see them. - * They are mutable, extension rewriting history accept to work on them. + * They are not exchanged with other repositories. pull//push do not see them. + * They are mutable, extensions rewriting history accept to work on them. -State of changeset have to be consistent with each other. A ``published`` +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 ancestor. +have ``published`` or ``ready`` ancestors. 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``) +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``). -Changeset will automatically move to ``published`` state when: +Changesets will automatically move to ``published`` state when: -* pushed to a repo that doesn't support ``ready`` state. +* pushed to a repo that doesn't support the ``ready`` state. * Tagged by a non local tag. Commands ........ -The extension add and ``hg states`` command to choose which state are used by a +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 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``.:: +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}`` have been added +A new template keyword ``{state}`` has 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**. +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 ouside ``.hg/hgrc`` -.................................................... +Why to you store activate state outside ``.hg/hgrc``? +..................................................... -``.hg/hgrc`` might be ignored for trust reason. we don't want the +``.hg/hgrc`` might be ignored for trust reason. we don't want the # XXX -Why is the ``dead`` state missing -.................................................... +Why is the ``dead`` state missing? +..................................................... -1. The ``dead`` state have a different behaviour that require more work to be -implemented +1. The ``dead`` state has a different behaviour that requires more work to be +implemented. -2. I believe that the usecase of ``dead changeset`` are better covered by the +2. I believe that the use cases of ``dead changeset`` are better covered by the ``obsolete`` extension. To Do ----- -* Moving boundary backward (code existist in ``liquid`` extension done at the +* Moving boundary backward (code exists in the ``liquid`` extension done at the CPH sprint) -* support for default value in configuration (when for init and clone) +* support for default value in configuration (for init and clone) -* stronger pull//push support (unknown remote head confuse the current code) +* stronger pull//push support (unknown remote heads confuse the current code) -* display the number of changeset that change state when activating a state. +* display the number of changesets that change state when activating a state. -* have a switch to select if changeset do change state on state activation. +* have a switch to select if changesets do change state on state activation. * proper revset directive. @@ -146,22 +148,25 @@ state: in progress -This extension introduce the *obsolete* concept. It adds a new *obsolete* relation between two changeset. A relation `` obsolete `` is set to denote that ```` is new version of ```` +This extension introduces the *obsolete* concept. It adds a new *obsolete* +relation between two changesets. A relation `` obsolete `` is set to denote that ```` is new version of ````. The *obsolete* relation act as a **perpendicular history** to the standard -changeset history. Standard changeset history versions files. When *obsolete* -relation versions changeset +changeset history. Standard changeset history versions files. The *obsolete* +relation versions changesets. Usage and Feature ------------------ -obsolete changeset are hidden. +obsolete changesets are hidden. Commands ........ -a ``debugobsolete`` command have been added. +a ``debugobsolete`` command has been added. To Do @@ -173,7 +178,7 @@ * exchange the obsolete information -* refuse to obsolete published changeset +* refuse to obsolete published changesets * handle split