|
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 |