Mercurial > evolve

changeset 35:0f98f87881bd

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Spelling fixes
author Julien Cristau <julien.cristau@logilab.fr>
date Mon, 01 Aug 2011 15:11:45 +0200
parents f28116682827
children 6531b01b2763
files README
diffstat 1 files changed, 62 insertions(+), 57 deletions(-) [+]
line wrap: on
line diff
--- 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 ``<changeset B> obsolete <changeset A>`` is set to denote that ``<changeset B>`` is new version of ``<changeset A>``
+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>``.
 
 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