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.