--- a/docs/evolve-collaboration.rst Tue Mar 27 17:51:09 2012 +0200
+++ b/docs/evolve-collaboration.rst Wed Mar 28 11:07:53 2012 +0200
@@ -7,7 +7,7 @@
After having written some code for ticket #42, M W. start a patch (this
will be kind of like a 'work-in-progress' checkpoint initially)::
- $ ci -m '[entities] remove magic'
+ $ hg ci -m '[entities] remove magic'
Instant patch ! Note how the default phase of this changeset is (still)
in "draft" state.
@@ -27,7 +27,7 @@
"publishing" since they do not have the notion of non-public changesets
(or mutable history).
-In the transition ... phase from older mercurial servers, this will
+During the transition from older mercurial servers to new ones, this will
happen often, so be careful.
Now let's come back to our patch. Next hour sees good progress and W.
@@ -44,7 +44,7 @@
$ hg push # was done with a modern mercurial, draft phase is preserved
-The next day, Mr C.W, which arrives very very early, can immediately
+The next day, Mr C.W., who arrives very early, can immediately
work out some glitches in the patch.
He then starts another one, for ticket #43 and finally commits it.
--- a/docs/evolve-faq.rst Tue Mar 27 17:51:09 2012 +0200
+++ b/docs/evolve-faq.rst Wed Mar 28 11:07:53 2012 +0200
@@ -8,7 +8,7 @@
Add a changeset: ``commit``
------------------------------------------------------------
-Just use commit as usual. New changeset will be in the `draft` phase.
+Just use commit as usual. New changesets will be in the `draft` phase.
Rewrite a changeset: ``amend``
------------------------------------------------------------
@@ -18,7 +18,7 @@
will work on any `draft` or `secret` changeset. It will not work on
`public` changesets.
-To understand what the result of amend will be I do use the two following
+To understand what the result of amend will be I use the two following
aliases [#]_::
# diff what amend will look likes
@@ -65,13 +65,13 @@
.. [#] add this `-O` to graft instead of a dedicated command is probably
- abusive. But this was very convenient for experimental purpose.
+ abusive. But this was very convenient for experimental purposes.
This will likely change in non experimental release.
Delete a changeset: ``kill``
------------------------------------------------------------
-A new ``kill`` command allows to remove a changeset.
+A new ``kill`` command allows removing a changeset.
Just use ``hg kill <some-rev>``.
@@ -88,18 +88,23 @@
.. note:: those command only exist for the convenience of getting qpush and qpop
feeling back.
-collapse changesets: ``amend``
+Collapse changesets: ``amend``
------------------------------------------------------------
you can use amend -c to collapse multiple changeset in a single one.
+Split changesets?
+-----------------------
+
+**TODO: Is it possible to split changesets, for example with record or crecord?**
+
Move multiple changesets: ``rebase``
------------------------------------------------------------
-You can still use rebase to move whole part of the changeset graph at once.
+You can still use rebase to move a whole segment of the changeset graph together.
-.. warning:: Beware that rebasing obsolete changeset will result in new
- conflicting version.
+.. warning:: Beware that rebasing obsolete changesets will result in
+ conflicting versions of the changesets.
Stabilize history: ``stabilize``
------------------------------------------------------------
@@ -108,7 +113,7 @@
those children you create *unstable* changesets and *suspended
obsolete* changesets.
-When you are finished amending a given changeset you will want to
+When you are finished amending a given changeset, you will want to
declare it stable, in other words rebase its former descendants on its
newest version. This is not done automatically to avoid the
proliferation of useless hidden changesets.
@@ -118,8 +123,8 @@
.. warning:: stabilization does not handle deletion yet.
-.. warning:: obsolete currently rely on secret changeset to not exchange
- obsolete and unstable changeset.
+.. warning:: obsolete currently relies on changesets in secret phase
+ to avoid exchanging obsolete and unstable changesets.
XXX details issue here
@@ -128,7 +133,7 @@
------------------------------------------------------------
Sometimes you need to create an obsolete marker by hand. This may happen when
-upstream has applied some of you patches for example.
+upstream has applied some of your patches for example.
you can use ``hg kill --new <new-changeset> <old-changeset>`` to add obsolete
marker.
--- a/docs/from-mq.rst Tue Mar 27 17:51:09 2012 +0200
+++ b/docs/from-mq.rst Wed Mar 28 11:07:53 2012 +0200
@@ -28,11 +28,11 @@
hg qseries
```````````
-All your work in progress are now real changeset all the time.
+All your work in progress is now in real changeset all the time.
-You can then use standard log to display them. You can use phase revset to
-display unfinished business only and template to have the same kind of compact
-output qseries have.
+You can use the standard log to display them. You can use the phase revset to
+display unfinished business only and templates to have the same kind of compact
+output qseries has.
This will result in something like that::
@@ -42,9 +42,9 @@
hg qnew
````````
-With evolve you handle standard changeset without additional overlay.
+With evolve you handle standard changesets without an additional overlay.
-Standard changeset are created using hg commit as usual.
+Standard changeset are created using hg commit as usual.::
$ hg commit
@@ -52,7 +52,7 @@
setting your changeset in the secret phase using the phase command.
Note that you only need it for the first commit you want to be secret. Later
-commit will inherit their parents phase.
+commits will inherit their parents phase.
If you always want your new commit to be in the secret phase, your should
consider updating your configuration:
@@ -69,11 +69,11 @@
$ hg amend
-This command takes the same option than commit plus useful switch '-e' (--edit)
-to edit the commit message.
+This command takes the same options as commit, plus the switch '-e' (--edit)
+to edit the commit message in an editor.
-Amend have also a -c switch which allow you to make and explicit amending
-commit before rewriting a changeset.
+Amend have also a -c switch which allow you to make an explicit amending
+commit before rewriting a changeset.::
$ hg record -m 'feature A'
# oups, I forget some stuff
@@ -99,19 +99,19 @@
hg qpush
````````
-When you rewrite changeset, descendant of rewritten changeset are marked as
-"out of sync". You new to rewrite them on top of the new version of their
+When you rewrite changesets, descendants of rewritten changesets are marked as
+"out of sync". You need to rewrite them on top of the new version of their
ancestor.
-The evolution extension add a command to rewrite the next changeset:
+The evolution extension adds a command to rewrite the "out of sync" changesets:::
$ hg stabilize
-You can also decide to do it manually using
+You can also decide to do it manually using::
$ hg graft -O <old-version>
-or
+or::
$ hg rebase -r <revset for old version> -d .
@@ -122,7 +122,7 @@
hg qrm
```````
-evolution introduce a new command to mark a changeset as "not wanted anymore".
+evolution introduce a new command to mark a changeset as "not wanted anymore".::
$ hg kill <revset>
@@ -139,27 +139,26 @@
or later::
$ hg collapse # XXX not implemented
-
$ hg rebase --collapse # XXX not tested
hg qdiff
`````````
-``odiff`` is an alias for `hg diff -r .^` it works as qdiff event outside mq.
+``odiff`` is an alias for `hg diff -r .^` it works as qdiff, but outside mq.
hg qfinish and hg qimport
````````````````````````````
-Is not useful anymore if you want to controll exchange and mutability of
-changeset see the phase feature
+Is not necessary anymore. If you want to control exchange and mutability of
+changesets, see the phase feature
hg qcommit
```````````````
-If you really need to send patches through a versionned mq patches you should
+If you really need to send patches through versioned mq patches, you should
look at the qsync extension.
--- a/docs/glossary.rst Tue Mar 27 17:51:09 2012 +0200
+++ b/docs/glossary.rst Wed Mar 28 11:07:53 2012 +0200
@@ -7,7 +7,7 @@
:obsolete marker:
express a relation from 0..n new changesets to 1 old changeset
:obsolete changesets:
- non public changeset target of a obsolete marker
+ non public changeset which are target of a obsolete marker
:unstable changeset:
changeset not obsolete but with obsolete ancestor
@@ -34,8 +34,8 @@
diff between a changeset and it's obsolete parent
:obsolete-tip:
- obsolete-descendants not obsolete themself.
+ obsolete-descendants which are not obsolete themselves.
:conflicting changeset:
multiple obsolete-tip for an obsolete changeset through diverging obsolete
- marker (no changeset split marker)
+ markers (no changeset split marker)
--- a/docs/index.rst Tue Mar 27 17:51:09 2012 +0200
+++ b/docs/index.rst Wed Mar 28 11:07:53 2012 +0200
@@ -62,7 +62,7 @@
$ hg clone http://hg-dev.octopoid.net/hgwebdir.cgi/mutable-history/
$ mutable-history/enable.sh >> ~/.hgrc
-You will probably want to use the associated version of hgview (QT viewer only)
+You will probably want to use the associated version of hgview (QT viewer only)::
$ hg clone http://hg-dev.octopoid.net/hgwebdir.cgi/hgview/
$ cd hgview
@@ -82,7 +82,7 @@
evolve-collaboration
qsync
-Smart changeset deletion: Obselete Marker
+Smart changeset deletion: Obsolete Marker
==========================================
Obsolete marker is a powerful concept that allow mercurial to safely handle
--- a/hgext/evolve.py Tue Mar 27 17:51:09 2012 +0200
+++ b/hgext/evolve.py Wed Mar 28 11:07:53 2012 +0200
@@ -21,7 +21,7 @@
from mercurial import commands
from mercurial import util
from mercurial.i18n import _
-from mercurial.commands import walkopts, commitopts, commitopts2, logopt
+from mercurial.commands import walkopts, commitopts, commitopts2, logopts
from mercurial import hg
### util function