Mercurial > evolve
comparison README.rst @ 5398:b3e178f3e31f
evolve: move README to rst
author | Sushil khanchi <sushilkhanchi97@gmail.com> |
---|---|
date | Wed, 08 Jul 2020 22:41:20 +0530 |
parents | README@85640f1feced |
children | 15b7c822cc46 |
comparison
equal
deleted
inserted
replaced
5397:03ce095dc10d | 5398:b3e178f3e31f |
---|---|
1 ============================= | |
2 Mutable History For Mercurial | |
3 ============================= | |
4 | |
5 Evolve Extension | |
6 ================= | |
7 | |
8 This package supplies the ``evolve`` extension for Mercurial, | |
9 | |
10 **The full implementation of the changeset evolution concept is still in | |
11 progress.** Please subscribe to the `evolve-testers mailing list | |
12 <https://www.mercurial-scm.org/mailman/listinfo/evolve-testers>`_ to stay up to | |
13 date with changes. | |
14 | |
15 This extension: | |
16 | |
17 * enables the "changeset evolution" feature of Mercurial core, | |
18 | |
19 * provides a set of commands to mutate your history, | |
20 | |
21 * issues several warning messages when troubles from some mutable appears in | |
22 your repository, | |
23 | |
24 * provides an ``hg evolve`` command to deal with such "troubles", | |
25 | |
26 * improves performance of obsolescence marker exchanges and discovery during | |
27 push and pull. | |
28 | |
29 Documentation | |
30 ------------- | |
31 | |
32 We recommend reading the documentation first. An online version is | |
33 available here: | |
34 | |
35 https://www.mercurial-scm.org/doc/evolution/ | |
36 | |
37 How to Install | |
38 ============== | |
39 | |
40 Using Pip | |
41 --------- | |
42 | |
43 You can install the latest evolution version usin pip:: | |
44 | |
45 $ pip install --user hg-evolve | |
46 | |
47 Then just enable it in you hgrc:: | |
48 | |
49 $ hg config --edit # adds the two line below: | |
50 [extensions] | |
51 evolve = | |
52 | |
53 From Source | |
54 ----------- | |
55 | |
56 To install a local version from source:: | |
57 | |
58 $ hg clone https://www.mercurial-scm.org/repo/evolve/ | |
59 $ cd evolve | |
60 $ pip install --user . | |
61 | |
62 Then just enable it in you hgrc:: | |
63 | |
64 $ hg config --edit # adds the two line below: | |
65 [extensions] | |
66 evolve = | |
67 | |
68 Documentation lives in ``doc/``. | |
69 | |
70 Server Only Setup | |
71 ================= | |
72 | |
73 It is possible to enable a smaller subset of the extensions aimed at server | |
74 serving repository. It skips the additions of the new commands and local UI | |
75 messages that might add performance overheads. To use the server only | |
76 extension, install the package and use:: | |
77 | |
78 $ hg config --edit # adds the two line below: | |
79 [extensions] | |
80 evolve.serveronly = | |
81 | |
82 Extension Purpose | |
83 ================= | |
84 | |
85 The goal of this extension is to provide an appropriate place for code and | |
86 concept related to changeset evolution to mature. In this extension we allow | |
87 for hackier code, unlocking quick experimentation and faster iterations. | |
88 | |
89 In addition, the evolve extensions support a wider set of Mercurial version, | |
90 allowing us to reach a larger user base for feedback. The Evolve extension is | |
91 not tight to the Mercurial release cycle and can release new feature and bug | |
92 fix at a higher rate if necessary. | |
93 | |
94 Once a concept is ready enough, its implementation is moved into Mercurial | |
95 core. The maturation period helped us to get a clearer picture of what was | |
96 needed. During the upstreaming process, we can use this clearer picture to | |
97 clean up the code and upgrade it to an appropriate quality for Mercurial core. | |
98 | |
99 Python 3 support | |
100 ================ | |
101 | |
102 Mercurial announced beta support for Python 3 starting with its 5.0 release. | |
103 Since 9.1.0, ``evolve`` has beta support for Python 3.6+. | |
104 | |
105 Support will stay in beta while Mercurial's support for Python 3 remains in | |
106 beta and until it is a bit more battle-tested. | |
107 | |
108 How to Contribute | |
109 ================= | |
110 | |
111 Discussion happens on the #hg-evolve IRC on freenode_. | |
112 | |
113 .. _freenode: https://freenode.net/ | |
114 | |
115 Bugs are to be reported on the mercurial's bug tracker (component: `evolution`_): | |
116 | |
117 .. _evolution: https://bz.mercurial-scm.org/buglist.cgi?component=evolution&query_format=advanced&resolution=--- | |
118 | |
119 The recommended way is to create Merge Request on | |
120 https://foss.heptapod.net/mercurial/evolve. To do so, create an account and | |
121 request access. You'll then be able to create topic based merge request. | |
122 | |
123 Alternatively, you can use the patchbomb extension to send email to `mercurial | |
124 devel <https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel>`_. | |
125 Please make sure to use the evolve-ext flag when doing so. You can use a | |
126 command like this:: | |
127 | |
128 $ hg email --to mercurial-devel@mercurial-scm.org --flag evolve-ext --rev '<your patches>' | |
129 | |
130 | |
131 For guidelines on the patch description, see the `official Mercurial guideline`_. | |
132 | |
133 .. _`official Mercurial guideline`: https://mercurial-scm.org/wiki/ContributingChanges#Patch_descriptions | |
134 | |
135 Please don't forget to update and run the tests when you fix a bug or | |
136 add a feature. To run the tests, you need a working copy of Mercurial, | |
137 say in $HGSRC:: | |
138 | |
139 $ cd tests | |
140 $ python $HGSRC/tests/run-tests.py | |
141 | |
142 When certain blocks of code need to cope with API changes in core Mercurial, | |
143 they should have comments in the ``hg <= x.y (commit hash)`` format. For | |
144 example, if a function needs another code path because of changes introduced in | |
145 02802fa87b74 that was first included in Mercurial 5.3, then the comment should | |
146 be:: | |
147 | |
148 # hg <= 5.2 (02802fa87b74) | |
149 | |
150 See also tests/test-check-compat-strings.t. | |
151 | |
152 Branch policy | |
153 ------------- | |
154 | |
155 The evolve tests are highly impacted by changes in core. To deal with this, we | |
156 use named branches. | |
157 | |
158 There are two main branches: "stable" and "default". Tests on these branches | |
159 are supposed to pass with the corresponding "default" and "stable" branch from | |
160 core Mercurial. The documentation is built from the tip of stable. | |
161 | |
162 In addition, we have compatibility branches to check tests on older versions of | |
163 Mercurial. They are the "mercurial-x.y" branches. They are used to apply | |
164 expected test changes only, no code changes should happen there. | |
165 | |
166 Test output changes from a changeset in core should add the following line to | |
167 their patch description: | |
168 | |
169 CORE-TEST-OUTPUT-UPDATE: <CORE-NODE-ID> | |
170 | |
171 | |
172 Format-source config | |
173 ==================== | |
174 | |
175 Format source helps smooth out the pain of merging after auto-formatting. | |
176 Follow the instructions for install here: | |
177 | |
178 .. _`format-source`: https://bitbucket.org/octobus/format-source | |
179 | |
180 Then update both your global and repo config files:: | |
181 | |
182 $ hg config -l # add the lines below | |
183 [extensions] | |
184 formatsource = | |
185 | |
186 [format-source] | |
187 byteify-strings = python3 ~/workspace/octobus/mercurial-devel/contrib/byteify-strings.py --dictiter --treat-as-kwargs kwargs opts commitopts TROUBLES --allow-attr-methods | |
188 byteify-strings:mode.input = file | |
189 byteify-strings:mode.output = pipe | |
190 | |
191 Release Checklist | |
192 ================= | |
193 | |
194 * make sure the tests are happy on all supported versions, | |
195 | |
196 You can use the `contrib/merge-test-compat.sh` to merge with the test | |
197 compatibility branches. | |
198 | |
199 * make sure there is no code difference between the compat branches and stable | |
200 (no diff within `hgext3rd/`), | |
201 | |
202 * update the `testedwith` variable for all extensions (remove '.dev'): | |
203 | |
204 - hgext3rd/evolve/metadata.py | |
205 - hgext3rd/topic/__init__.py | |
206 - hgext3rd/pullbundle.py | |
207 | |
208 * make sure the changelog is up to date, | |
209 | |
210 * add a date to the changelog entry for the target version, | |
211 | |
212 * update the `__version__` field of all relevant extensions: | |
213 | |
214 - hgext3rd/evolve/metadata.py | |
215 - hgext3rd/topic/__init__.py | |
216 - hgext3rd/pullbundle.py (if touched) | |
217 | |
218 * create a new Debian entry: | |
219 | |
220 - debchange --newversion x.y.z-1 "new upstream release" | |
221 - debchange --release | |
222 | |
223 * sanity check install and sdist targets of setup.py: | |
224 | |
225 - python setup.py install --home=$(mktemp -d) | |
226 - python setup.py sdist | |
227 | |
228 * tag the commit, | |
229 | |
230 * push and publish the tag, | |
231 | |
232 * upload the tarball to PyPI, | |
233 | |
234 * make an announcement on evolve-testers@mercurial-scm.org (possibly on | |
235 mercurial@mercurial-scm.org too), | |
236 | |
237 * bump versions of all extensions and add '.dev' (see existing commits as an | |
238 example): | |
239 | |
240 - hgext3rd/evolve/metadata.py | |
241 - hgext3rd/topic/__init__.py | |
242 - hgext3rd/pullbundle.py | |
243 | |
244 The version we use on the stable branch during development should be | |
245 `x.y.z+1.dev`. The version of the default branch should be `x.y+1.0.dev`. | |
246 | |
247 * merge stable into default. |