wenzelm@28907
|
1 |
Important notes on Mercurial repository access for Isabelle
|
wenzelm@28907
|
2 |
===========================================================
|
wenzelm@28907
|
3 |
|
wenzelm@51468
|
4 |
Quick start in 25min
|
wenzelm@50363
|
5 |
--------------------
|
wenzelm@50363
|
6 |
|
wenzelm@52734
|
7 |
1a. Linux and Mac OS X: ensure that Perl (with libwww) and Mercurial (hg)
|
wenzelm@52734
|
8 |
is installed (see also http://www.selenic.com/mercurial)
|
wenzelm@51668
|
9 |
|
wenzelm@52734
|
10 |
1b. Windows: ensure that Cygwin with Mercurial and Perl is installed (see
|
wenzelm@52734
|
11 |
also http://www.cygwin.com)
|
wenzelm@51468
|
12 |
|
wenzelm@51668
|
13 |
2. Clone repository (bash shell commands):
|
wenzelm@50363
|
14 |
|
wenzelm@50363
|
15 |
hg clone http://isabelle.in.tum.de/repos/isabelle
|
wenzelm@50363
|
16 |
|
wenzelm@51590
|
17 |
cd isabelle
|
wenzelm@50363
|
18 |
|
wenzelm@51668
|
19 |
./bin/isabelle components -I
|
wenzelm@51668
|
20 |
|
wenzelm@51590
|
21 |
./bin/isabelle components -a
|
wenzelm@50363
|
22 |
|
wenzelm@51590
|
23 |
./bin/isabelle jedit -l HOL
|
wenzelm@50363
|
24 |
|
wenzelm@52639
|
25 |
./bin/isabelle build -b HOL #optional: build session image manually
|
wenzelm@52639
|
26 |
|
wenzelm@51668
|
27 |
3. Update repository (bash shell commands):
|
wenzelm@51296
|
28 |
|
wenzelm@51296
|
29 |
cd isabelle
|
wenzelm@51296
|
30 |
|
wenzelm@51296
|
31 |
hg pull -u
|
wenzelm@51296
|
32 |
|
wenzelm@51590
|
33 |
./bin/isabelle components -a
|
wenzelm@51590
|
34 |
|
wenzelm@51590
|
35 |
./bin/isabelle jedit -l HOL
|
wenzelm@51590
|
36 |
|
wenzelm@52639
|
37 |
./bin/isabelle jedit -b -f #optional: force fresh build of Isabelle/Scala
|
wenzelm@52639
|
38 |
|
wenzelm@52639
|
39 |
4. Access documentation (bash shell commands):
|
wenzelm@52639
|
40 |
|
wenzelm@54496
|
41 |
./bin/isabelle build_doc -a
|
wenzelm@52639
|
42 |
|
wenzelm@52639
|
43 |
./bin/isabelle doc system
|
wenzelm@52639
|
44 |
|
wenzelm@50363
|
45 |
|
wenzelm@40849
|
46 |
Introduction
|
wenzelm@40849
|
47 |
------------
|
wenzelm@28907
|
48 |
|
wenzelm@40849
|
49 |
Mercurial http://www.selenic.com/mercurial belongs to the current
|
wenzelm@40849
|
50 |
generation of source code management systems that follow the so-called
|
wenzelm@40849
|
51 |
paradigm of "distributed version control". This is a terrific name
|
wenzelm@40849
|
52 |
for plain revision control without the legacy of CVS or SVN. See also
|
wenzelm@40849
|
53 |
http://hginit.com/ for an introduction to the main ideas. The
|
wenzelm@40849
|
54 |
Mercurial book http://hgbook.red-bean.com/ explains many more details.
|
wenzelm@28907
|
55 |
|
wenzelm@40849
|
56 |
Mercurial offers great flexibility in organizing the flow of changes,
|
wenzelm@40849
|
57 |
both between individual developers and designated pull/push areas that
|
wenzelm@40849
|
58 |
are shared with others. This additional power demands some additional
|
wenzelm@40849
|
59 |
responsibility to maintain a certain development process that fits to
|
wenzelm@40849
|
60 |
a particular project.
|
wenzelm@28907
|
61 |
|
wenzelm@40849
|
62 |
Regular Mercurial operations are strictly monotonic, where changeset
|
wenzelm@52639
|
63 |
transactions are only added, but never deleted or mutated. There are
|
wenzelm@52639
|
64 |
special tools to manipulate repositories via non-monotonic actions
|
wenzelm@52639
|
65 |
(such as "rollback" or "strip"), but recovering from gross mistakes
|
wenzelm@52639
|
66 |
that have escaped into the public can be hard and embarrassing. It is
|
wenzelm@52639
|
67 |
much easier to inspect and amend changesets routinely before pushing.
|
wenzelm@40849
|
68 |
|
wenzelm@40849
|
69 |
The effect of the critical "pull" / "push" operations can be tested in
|
wenzelm@40849
|
70 |
a dry run via "incoming" / "outgoing". The "fetch" extension includes
|
wenzelm@52639
|
71 |
useful sanity checks beyond raw "pull" / "update" / "merge", although
|
wenzelm@52639
|
72 |
it has lost popularity in recent years. Most other operations are
|
wenzelm@52639
|
73 |
local to the user's repository clone. This gives some freedom for
|
wenzelm@52639
|
74 |
experimentation without affecting anybody else.
|
wenzelm@40849
|
75 |
|
wenzelm@40849
|
76 |
Mercurial provides nice web presentation of incoming changes with a
|
wenzelm@40849
|
77 |
digest of log entries; this also includes RSS/Atom news feeds. There
|
wenzelm@48320
|
78 |
are add-on history browsers such as "hg view" and TortoiseHg. Unlike
|
wenzelm@48320
|
79 |
the default web view, some of these tools help to inspect the semantic
|
wenzelm@48320
|
80 |
content of non-trivial merge nodes.
|
wenzelm@28907
|
81 |
|
wenzelm@28907
|
82 |
|
wenzelm@28907
|
83 |
Initial configuration
|
wenzelm@29481
|
84 |
---------------------
|
wenzelm@28907
|
85 |
|
wenzelm@52639
|
86 |
The main Isabelle repository can be cloned like this:
|
wenzelm@28907
|
87 |
|
wenzelm@28907
|
88 |
hg clone http://isabelle.in.tum.de/repos/isabelle
|
wenzelm@28907
|
89 |
|
wenzelm@28907
|
90 |
This will create a local directory "isabelle", unless an alternative
|
wenzelm@28907
|
91 |
name is specified. The full repository meta-data and history of
|
wenzelm@28907
|
92 |
changes is in isabelle/.hg; local configuration for this clone can be
|
wenzelm@28907
|
93 |
added to isabelle/.hg/hgrc, but note that hgrc files are never copied
|
wenzelm@40849
|
94 |
by another clone operation.
|
wenzelm@28907
|
95 |
|
wenzelm@28917
|
96 |
|
wenzelm@28913
|
97 |
There is also $HOME/.hgrc for per-user Mercurial configuration. The
|
wenzelm@40849
|
98 |
initial configuration requires at least an entry to identify yourself
|
wenzelm@40849
|
99 |
as follows:
|
wenzelm@28907
|
100 |
|
wenzelm@28907
|
101 |
[ui]
|
wenzelm@40849
|
102 |
username = XXX
|
wenzelm@28907
|
103 |
|
wenzelm@40849
|
104 |
Isabelle contributors are free to choose either a short "login name"
|
wenzelm@40849
|
105 |
(for accounts at TU Munich) or a "full name" -- with or without mail
|
wenzelm@40849
|
106 |
address. It is important to stick to this choice once and for all.
|
wenzelm@40849
|
107 |
The machine default that Mercurial produces for unspecified
|
wenzelm@40849
|
108 |
[ui]username is not appropriate.
|
wenzelm@28907
|
109 |
|
wenzelm@40849
|
110 |
Such configuration can be given in $HOME/.hgrc (for each home
|
wenzelm@40849
|
111 |
directory on each machine) or in .hg/hgrc (for each repository clone).
|
wenzelm@28907
|
112 |
|
wenzelm@28907
|
113 |
|
wenzelm@40849
|
114 |
Here are some further examples for hgrc. This is how to provide
|
wenzelm@40849
|
115 |
default options for common commands:
|
wenzelm@28907
|
116 |
|
wenzelm@28907
|
117 |
[defaults]
|
wenzelm@28907
|
118 |
log = -l 10
|
wenzelm@28907
|
119 |
|
wenzelm@40849
|
120 |
This is how to configure some extension, which is called "graphlog"
|
wenzelm@40849
|
121 |
and provides the "glog" command:
|
wenzelm@28907
|
122 |
|
wenzelm@28907
|
123 |
[extensions]
|
wenzelm@28907
|
124 |
hgext.graphlog =
|
wenzelm@28907
|
125 |
|
wenzelm@28907
|
126 |
|
wenzelm@28907
|
127 |
Shared pull/push access
|
wenzelm@29481
|
128 |
-----------------------
|
wenzelm@28907
|
129 |
|
wenzelm@28907
|
130 |
The entry point http://isabelle.in.tum.de/repos/isabelle is world
|
wenzelm@28907
|
131 |
readable, both via plain web browsing and the hg client as described
|
wenzelm@40849
|
132 |
above. Anybody can produce a clone, change it locally, and then use
|
wenzelm@40849
|
133 |
regular mechanisms of Mercurial to report changes upstream, say via
|
wenzelm@40849
|
134 |
mail to someone with write access to that file space. It is also
|
wenzelm@40849
|
135 |
quite easy to publish changed clones again on the web, using the
|
wenzelm@40849
|
136 |
ad-hoc command "hg serve -v", or the hgweb.cgi or hgwebdir.cgi scripts
|
wenzelm@40849
|
137 |
that are included in the Mercurial distribution, and send a "pull
|
wenzelm@40849
|
138 |
request" to someone else. There are also public hosting services for
|
wenzelm@52639
|
139 |
Mercurial repositories, notably Bitbucket.
|
wenzelm@28907
|
140 |
|
wenzelm@28913
|
141 |
The downstream/upstream mode of operation is quite common in the
|
wenzelm@28907
|
142 |
distributed version control community, and works well for occasional
|
wenzelm@28907
|
143 |
changes produced by anybody out there. Of course, upstream
|
wenzelm@28907
|
144 |
maintainers need to review and moderate changes being proposed, before
|
wenzelm@40849
|
145 |
pushing anything onto the official Isabelle repository at TUM. Direct
|
wenzelm@40849
|
146 |
pushes are also reviewed routinely in a post-hoc fashion; everybody
|
wenzelm@40849
|
147 |
hooked on the main repository is called to keep an eye on incoming
|
wenzelm@52639
|
148 |
changes. In any case, changesets need to be understandable, both at
|
wenzelm@52639
|
149 |
the time of writing and many years later.
|
wenzelm@28907
|
150 |
|
wenzelm@40849
|
151 |
Push access to the Isabelle repository requires an account at TUM,
|
wenzelm@52040
|
152 |
with properly configured ssh to isabelle-server.in.tum.de. You also
|
wenzelm@52040
|
153 |
need to be a member of the "isabelle" Unix group.
|
wenzelm@28907
|
154 |
|
wenzelm@28913
|
155 |
Sharing a locally modified clone then works as follows, using your
|
wenzelm@28913
|
156 |
user name instead of "wenzelm":
|
wenzelm@28907
|
157 |
|
wenzelm@52040
|
158 |
hg out ssh://wenzelm@isabelle-server.in.tum.de//home/isabelle-repository/repos/isabelle
|
wenzelm@28907
|
159 |
|
wenzelm@28913
|
160 |
In fact, the "out" or "outgoing" command performs only a dry run: it
|
wenzelm@28913
|
161 |
displays the changesets that would get published. An actual "push",
|
wenzelm@28913
|
162 |
with a lasting effect on the Isabelle repository, works like this:
|
wenzelm@28907
|
163 |
|
wenzelm@52040
|
164 |
hg push ssh://wenzelm@isabelle-server.in.tum.de//home/isabelle-repository/repos/isabelle
|
wenzelm@28907
|
165 |
|
wenzelm@28913
|
166 |
|
wenzelm@40849
|
167 |
Default paths for push and pull can be configured in
|
wenzelm@40849
|
168 |
isabelle/.hg/hgrc, for example:
|
wenzelm@28907
|
169 |
|
wenzelm@28907
|
170 |
[paths]
|
wenzelm@52040
|
171 |
default = ssh://wenzelm@isabelle-server.in.tum.de//home/isabelle-repository/repos/isabelle
|
wenzelm@28907
|
172 |
|
wenzelm@28913
|
173 |
Now "hg pull" or "hg push" will use that shared file space, unless a
|
wenzelm@28913
|
174 |
different URL is specified explicitly.
|
wenzelm@28913
|
175 |
|
wenzelm@28913
|
176 |
When cloning a repository, the default path is set to the initial
|
wenzelm@28913
|
177 |
source URL. So we could have cloned via that ssh URL in the first
|
wenzelm@28913
|
178 |
place, to get exactly to the same point:
|
wenzelm@28913
|
179 |
|
wenzelm@52040
|
180 |
hg clone ssh://wenzelm@isabelle-server.in.tum.de//home/isabelle-repository/repos/isabelle
|
wenzelm@28907
|
181 |
|
wenzelm@28907
|
182 |
|
wenzelm@40849
|
183 |
Simple merges
|
wenzelm@40849
|
184 |
-------------
|
wenzelm@30182
|
185 |
|
wenzelm@30182
|
186 |
The main idea of Mercurial is to let individual users produce
|
wenzelm@30182
|
187 |
independent branches of development first, but merge with others
|
wenzelm@30182
|
188 |
frequently. The basic hg merge operation is more general than
|
wenzelm@30182
|
189 |
required for the mode of operation with a shared pull/push area. The
|
wenzelm@40849
|
190 |
"fetch" extension accommodates this case nicely, automating trivial
|
wenzelm@30182
|
191 |
merges and requiring manual intervention for actual conflicts only.
|
wenzelm@30182
|
192 |
|
wenzelm@40849
|
193 |
The fetch extension can be configured via $HOME/.hgrc like this:
|
wenzelm@30182
|
194 |
|
wenzelm@30182
|
195 |
[extensions]
|
wenzelm@30182
|
196 |
hgext.fetch =
|
wenzelm@30182
|
197 |
|
wenzelm@30182
|
198 |
[defaults]
|
wenzelm@30182
|
199 |
fetch = -m "merged"
|
wenzelm@30182
|
200 |
|
wenzelm@40849
|
201 |
To keep merges semantically trivial and prevent genuine merge
|
wenzelm@40849
|
202 |
conflicts or lost updates, it is essential to observe to following
|
wenzelm@40849
|
203 |
general discipline wrt. the public Isabelle push area:
|
wenzelm@40849
|
204 |
|
wenzelm@40849
|
205 |
* Before editing, pull or fetch the latest version.
|
wenzelm@40849
|
206 |
|
wenzelm@40849
|
207 |
* Accumulate private commits for a maximum of 1-3 days.
|
wenzelm@40849
|
208 |
|
wenzelm@40849
|
209 |
* Start publishing again by pull or fetch, which normally produces
|
wenzelm@40849
|
210 |
local merges.
|
wenzelm@40849
|
211 |
|
wenzelm@51296
|
212 |
* Test the merged result, e.g. like this:
|
wenzelm@51296
|
213 |
|
wenzelm@51296
|
214 |
isabelle build -a
|
wenzelm@51296
|
215 |
|
wenzelm@51296
|
216 |
* Push back in real time.
|
wenzelm@40849
|
217 |
|
wenzelm@40849
|
218 |
Piling private changes and public merges longer than 0.5-2 hours is
|
wenzelm@40849
|
219 |
apt to produce some mess when pushing eventually!
|
wenzelm@30182
|
220 |
|
wenzelm@51296
|
221 |
The pull-test-push cycle should not be repeated too fast, to avoid
|
wenzelm@51296
|
222 |
delaying others from doing the same concurrently.
|
wenzelm@51296
|
223 |
|
wenzelm@30182
|
224 |
|
wenzelm@28907
|
225 |
Content discipline
|
wenzelm@29481
|
226 |
------------------
|
wenzelm@28907
|
227 |
|
wenzelm@40849
|
228 |
The following principles should be kept in mind when producing
|
wenzelm@40849
|
229 |
changesets that are meant to be published at some point.
|
wenzelm@28907
|
230 |
|
wenzelm@40849
|
231 |
* The author of changes needs to be properly identified, using
|
wenzelm@40849
|
232 |
[ui]username configuration as described above.
|
wenzelm@28907
|
233 |
|
wenzelm@28907
|
234 |
While Mercurial also provides means for signed changesets, we want
|
wenzelm@28907
|
235 |
to keep things simple and trust that users specify their identity
|
wenzelm@40849
|
236 |
correctly (and uniquely).
|
wenzelm@28907
|
237 |
|
wenzelm@28907
|
238 |
* The history of sources is an integral part of the sources
|
wenzelm@28907
|
239 |
themselves. This means that private experiments and branches
|
wenzelm@40849
|
240 |
should not be published by accident. Named branches are not
|
wenzelm@40849
|
241 |
allowed on the public version. Note that old SVN-style branching
|
wenzelm@40849
|
242 |
is replaced by regular repository clones in Mercurial.
|
wenzelm@28907
|
243 |
|
wenzelm@40849
|
244 |
Exchanging local experiments with some other users can be done
|
wenzelm@40849
|
245 |
directly on peer-to-peer basis, without affecting the central
|
wenzelm@40849
|
246 |
pull/push area.
|
wenzelm@28907
|
247 |
|
wenzelm@28907
|
248 |
* Log messages are an integral part of the history of sources.
|
wenzelm@40849
|
249 |
Other people will have to inspect them routinely, to understand
|
wenzelm@40849
|
250 |
why things have been done in a certain way at some point.
|
wenzelm@28907
|
251 |
|
wenzelm@40849
|
252 |
Authors of log entries should be aware that published changes are
|
wenzelm@40849
|
253 |
actually read. The main point is not to announce novelties, but
|
wenzelm@40849
|
254 |
to describe faithfully what has been done, and provide some clues
|
wenzelm@40849
|
255 |
about the motivation behind it. The main recipient is someone who
|
wenzelm@40849
|
256 |
needs to understand the change in the distant future to isolate
|
wenzelm@52639
|
257 |
problems. Sometimes it is helpful to reference past changes
|
wenzelm@52639
|
258 |
formally via changeset ids in the log entry.
|
wenzelm@28907
|
259 |
|
wenzelm@40849
|
260 |
* The standard changelog entry format of the Isabelle repository
|
wenzelm@52639
|
261 |
admits several (somehow related) items to be rolled into one
|
wenzelm@40849
|
262 |
changeset. Each item is then described on a separate line that
|
wenzelm@40849
|
263 |
may become longer as screen line and is terminated by punctuation.
|
wenzelm@40849
|
264 |
These lines are roughly ordered by importance.
|
wenzelm@40849
|
265 |
|
wenzelm@40849
|
266 |
This format conforms to established Isabelle tradition. In
|
wenzelm@40849
|
267 |
contrast, the default of Mercurial prefers a single headline
|
wenzelm@40849
|
268 |
followed by a long body text. The reason for that is a somewhat
|
wenzelm@40849
|
269 |
different development model of typical "distributed" projects,
|
wenzelm@40849
|
270 |
where external changes pass through a hierarchy of reviewers and
|
wenzelm@40849
|
271 |
maintainers, until they end up in some authoritative repository.
|
wenzelm@40849
|
272 |
Isabelle changesets can be more spontaneous, growing from the
|
wenzelm@40849
|
273 |
bottom-up.
|
wenzelm@40849
|
274 |
|
wenzelm@40849
|
275 |
The web style of http://isabelle.in.tum.de/repos/isabelle/
|
wenzelm@40849
|
276 |
accommodates the Isabelle changelog format. Note that multiple
|
wenzelm@40849
|
277 |
lines will sometimes display as a single paragraph in HTML, so
|
wenzelm@40849
|
278 |
some terminating punctuation is required. Do not squeeze multiple
|
wenzelm@40849
|
279 |
items on the same line in the original text!
|
wenzelm@28907
|
280 |
|
wenzelm@28907
|
281 |
|
wenzelm@52639
|
282 |
Testing of changes (before push)
|
wenzelm@52639
|
283 |
--------------------------------
|
wenzelm@28908
|
284 |
|
wenzelm@52639
|
285 |
The integrity of the standard pull/push area of Isabelle needs the be
|
wenzelm@52639
|
286 |
preserved at all time. This means that a complete test with default
|
wenzelm@52639
|
287 |
configuration needs to be finished successfully before push. If the
|
wenzelm@52639
|
288 |
preparation of the push involves a pull/merge phase, its result needs
|
wenzelm@52639
|
289 |
to covered by the test as well.
|
wenzelm@28908
|
290 |
|
wenzelm@52639
|
291 |
There are several possibilities to perform the test, e.g. using the
|
wenzelm@52639
|
292 |
Isabelle testboard at TUM. In contrast, the subsequent command-line
|
wenzelm@52639
|
293 |
examples are for tests on the local machine:
|
wenzelm@49512
|
294 |
|
wenzelm@52639
|
295 |
./bin/isabelle build -a #regular test
|
wenzelm@49512
|
296 |
|
wenzelm@52639
|
297 |
./bin/isabelle build -a -o document=pdf #test with document preparation
|
wenzelm@49512
|
298 |
|
wenzelm@52639
|
299 |
./bin/isabelle build -a -j2 -o threads=4 #test on multiple cores (example)
|
wenzelm@49512
|
300 |
|
wenzelm@52639
|
301 |
See also the chapter on Isabelle sessions and build management in the
|
wenzelm@52639
|
302 |
"system" manual.
|
wenzelm@49859
|
303 |
|
wenzelm@52639
|
304 |
Note that implicit dependencies on Isabelle components are specified
|
wenzelm@52639
|
305 |
via catalog files in $ISABELLE_HOME/Admin/components/ as part of the
|
wenzelm@52639
|
306 |
Mercurial history. This allows to bisect over a range of Isabelle
|
wenzelm@52639
|
307 |
versions while references to the contributing components change
|
wenzelm@52639
|
308 |
accordingly. Recall that "isabelle components -a" updates the local
|
wenzelm@52639
|
309 |
component store monotonically according to that information, and thus
|
wenzelm@52639
|
310 |
resolves missing components.
|