Mercurial > evolve

comparison README @ 33:dca86448d736

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Add some doc.
author Pierre-Yves David <pierre-yves.david@logilab.fr>
date Mon, 01 Aug 2011 14:12:48 +0200
parents
children f28116682827
comparison
equal deleted inserted replaced
32:c27491be4431 33:dca86448d736
1 =============================
2 Mutable History For Mercurial
3 =============================
4
5 This repository hold several experimental extension that introduce concept
6 related to history rewriting in mercurial. You will find three different
7 extensions.
8
9 :states:
10
11 Introduce a state concept. It allow to track which changeset have been make
12 public and immutable and which you want to keep local.
13
14 :obsolete:
15
16 Introduce an obsolete concept that track new version of rewritten changeset.
17
18 :rewrite:
19 A collection of command to rewrite the mutable part of the history.
20
21
22
23 **These extensions are experimental and are not meant for production.**
24
25
26 States Extension
27 ======================
28
29 state: experimentally functional
30
31 (see http://mercurial.selenic.com/wiki/StatesPlan)
32
33 This extension the state concept. A changeset now have one of the following *state*:
34
35 :published:
36
37 Changeset in the ``published`` state are the core of the history. They are
38 changeset that you published to the world. People can expect them to always
39 be exist. This is changeset as you know them. **By default all changeset
40 are published**
41
42 * They are exchanged with other repository (included in pull//push).
43
44 * They are not mutable, extension rewriting history should refuse to
45 rewrite them.
46
47 :ready:
48
49 Changeset in the ``ready`` state have not been accepted in the immutable
50 history yet. You can share them with other for review, testing or
51 improvement. Any ``ready`` changeset can either be included in the
52 published history (and become immutable) or be rewritten and rever make it
53 the published history.
54
55 * They are exchanged with other repository (included in pull//push).
56 * They are mutable, extension rewriting history accept to work on them.
57
58 :draft:
59
60 Changeset in the ``draft`` state are heavy work in progress you are
61 currently working on without willing to share with other.
62
63 * They are not exchanged with other repository. pull//push does not see them.
64 * They are mutable, extension rewriting history accept to work on them.
65
66
67 State of changeset have to be consistent with each other. A ``published``
68 changeset can only have ``published`` ancestors. A ``ready`` changeset can only
69 have ``published`` or ready ancestor.
70
71
72 Usage and Feature
73 ------------------
74
75 By default all changeset in the repository are ``published``. Other state must
76 be explicitly activated. When a state is not activated, changeset of this state
77 are handled as changeset of the state before him. (``draft`` are handled as
78 ``ready``, ``ready`` are handled as ``published``)
79
80 Changeset will automatically move to ``published`` state when:
81
82 * pushed to a repo that doesn't support ``ready`` state.
83
84 * Tagged by a non local tag.
85
86 Commands
87 ........
88
89 The extension add and ``hg states`` command to choose which state are used by a
90 repository, see ``hg help states for details``.
91
92 A command is also added for all active states. The command have the name of the
93 states and is used to manually change the state of a changeset. This is mainly
94 usefull to move changeset from ``draft`` to ``ready``.::
95
96 hg ready tip
97
98 Template
99 ........
100
101 A new template keyword ``{state}`` have been added
102
103 Revset
104 ........
105
106 We add a new ``readyheads()`` and ``publishedheads()`` revset directive. This return the heads of each states **as if all of them was activated**.
107
108 FAQ
109 ---
110
111 Why to you store activate state ouside ``.hg/hgrc``
112 ....................................................
113
114 ``.hg/hgrc`` might be ignored for trust reason. we don't want the
115
116 Why is the ``dead`` state missing
117 ....................................................
118
119 1. The ``dead`` state have a different behaviour that require more work to be
120 implemented
121
122 2. I believe that the usecase of ``dead changeset`` are better covered by the
123 ``obsolete`` extension.
124
125 To Do
126 -----
127
128 * Moving boundary backward (code existist in ``liquid`` extension done at the
129 CPH sprint)
130
131 * support for default value in configuration (when for init and clone)
132
133 * stronger pull//push support (unknown remote head confuse the current code)
134
135 * display the number of changeset that change state when activating a state.
136
137 * have a switch to select if changeset do change state on state activation.
138
139 * proper revset directive.
140
141
142
143
144 Obsolete Extension
145 ======================
146
147 state: in progress
148
149 Usage and Feature
150 ------------------
151
152 obsolete changeset are hidden.
153
154 Commands
155 ........
156
157
158 a ``debugobsolete`` command have been added.
159
160
161 To Do
162 -----
163
164 * do not exchange them
165
166 * handle non-obsolete children
167
168 * exchange the obsolete information
169
170 * refuse to obsolete published changeset
171
172 * handle split
173
174 * handle conflict
175
176 * handle out of sync
177
178 rewrite Extension
179 ======================
180
181 state: To be written
182