wenzelm@28907
|
1 |
Important notes on Mercurial repository access for Isabelle
|
wenzelm@28907
|
2 |
===========================================================
|
wenzelm@28907
|
3 |
|
wenzelm@40849
|
4 |
Introduction
|
wenzelm@40849
|
5 |
------------
|
wenzelm@28907
|
6 |
|
wenzelm@40849
|
7 |
Mercurial http://www.selenic.com/mercurial belongs to the current
|
wenzelm@40849
|
8 |
generation of source code management systems that follow the so-called
|
wenzelm@40849
|
9 |
paradigm of "distributed version control". This is a terrific name
|
wenzelm@40849
|
10 |
for plain revision control without the legacy of CVS or SVN. See also
|
wenzelm@40849
|
11 |
http://hginit.com/ for an introduction to the main ideas. The
|
wenzelm@40849
|
12 |
Mercurial book http://hgbook.red-bean.com/ explains many more details.
|
wenzelm@28907
|
13 |
|
wenzelm@40849
|
14 |
Mercurial offers great flexibility in organizing the flow of changes,
|
wenzelm@40849
|
15 |
both between individual developers and designated pull/push areas that
|
wenzelm@40849
|
16 |
are shared with others. This additional power demands some additional
|
wenzelm@40849
|
17 |
responsibility to maintain a certain development process that fits to
|
wenzelm@40849
|
18 |
a particular project.
|
wenzelm@28907
|
19 |
|
wenzelm@40849
|
20 |
Regular Mercurial operations are strictly monotonic, where changeset
|
wenzelm@40849
|
21 |
transactions are only added, but never deleted. There are special
|
wenzelm@40849
|
22 |
tools to manipulate repositories via non-monotonic actions (such as
|
wenzelm@40849
|
23 |
"rollback" or "strip"), but recovering from gross mistakes that have
|
wenzelm@40849
|
24 |
escaped into the public can be hard and embarrassing. It is much
|
wenzelm@40849
|
25 |
easier to inspect and amend changesets routinely before pushing.
|
wenzelm@40849
|
26 |
|
wenzelm@40849
|
27 |
The effect of the critical "pull" / "push" operations can be tested in
|
wenzelm@40849
|
28 |
a dry run via "incoming" / "outgoing". The "fetch" extension includes
|
wenzelm@40849
|
29 |
useful sanity checks beyond raw "pull" / "update" / "merge". Most
|
wenzelm@40849
|
30 |
other operations are local to the user's repository clone. This gives
|
wenzelm@40849
|
31 |
some freedom for experimentation without affecting anybody else.
|
wenzelm@40849
|
32 |
|
wenzelm@40849
|
33 |
Mercurial provides nice web presentation of incoming changes with a
|
wenzelm@40849
|
34 |
digest of log entries; this also includes RSS/Atom news feeds. There
|
wenzelm@40849
|
35 |
are add-on browsers, notably hgtk that is part of the TortoiseHg
|
wenzelm@40849
|
36 |
distribution and works for generic Python/GTk platforms. The
|
wenzelm@40849
|
37 |
alternative "view" utility helps to inspect the semantic content of
|
wenzelm@40849
|
38 |
merge nodes.
|
wenzelm@28907
|
39 |
|
wenzelm@28907
|
40 |
|
wenzelm@28907
|
41 |
Initial configuration
|
wenzelm@29481
|
42 |
---------------------
|
wenzelm@28907
|
43 |
|
wenzelm@28913
|
44 |
The official Isabelle repository can be cloned like this:
|
wenzelm@28907
|
45 |
|
wenzelm@28907
|
46 |
hg clone http://isabelle.in.tum.de/repos/isabelle
|
wenzelm@28907
|
47 |
|
wenzelm@28907
|
48 |
This will create a local directory "isabelle", unless an alternative
|
wenzelm@28907
|
49 |
name is specified. The full repository meta-data and history of
|
wenzelm@28907
|
50 |
changes is in isabelle/.hg; local configuration for this clone can be
|
wenzelm@28907
|
51 |
added to isabelle/.hg/hgrc, but note that hgrc files are never copied
|
wenzelm@40849
|
52 |
by another clone operation.
|
wenzelm@28907
|
53 |
|
wenzelm@28917
|
54 |
|
wenzelm@28913
|
55 |
There is also $HOME/.hgrc for per-user Mercurial configuration. The
|
wenzelm@40849
|
56 |
initial configuration requires at least an entry to identify yourself
|
wenzelm@40849
|
57 |
as follows:
|
wenzelm@28907
|
58 |
|
wenzelm@28907
|
59 |
[ui]
|
wenzelm@40849
|
60 |
username = XXX
|
wenzelm@28907
|
61 |
|
wenzelm@40849
|
62 |
Isabelle contributors are free to choose either a short "login name"
|
wenzelm@40849
|
63 |
(for accounts at TU Munich) or a "full name" -- with or without mail
|
wenzelm@40849
|
64 |
address. It is important to stick to this choice once and for all.
|
wenzelm@40849
|
65 |
The machine default that Mercurial produces for unspecified
|
wenzelm@40849
|
66 |
[ui]username is not appropriate.
|
wenzelm@28907
|
67 |
|
wenzelm@40849
|
68 |
Such configuration can be given in $HOME/.hgrc (for each home
|
wenzelm@40849
|
69 |
directory on each machine) or in .hg/hgrc (for each repository clone).
|
wenzelm@28907
|
70 |
|
wenzelm@28907
|
71 |
|
wenzelm@40849
|
72 |
Here are some further examples for hgrc. This is how to provide
|
wenzelm@40849
|
73 |
default options for common commands:
|
wenzelm@28907
|
74 |
|
wenzelm@28907
|
75 |
[defaults]
|
wenzelm@28907
|
76 |
log = -l 10
|
wenzelm@28907
|
77 |
|
wenzelm@40849
|
78 |
This is how to configure some extension, which is called "graphlog"
|
wenzelm@40849
|
79 |
and provides the "glog" command:
|
wenzelm@28907
|
80 |
|
wenzelm@28907
|
81 |
[extensions]
|
wenzelm@28907
|
82 |
hgext.graphlog =
|
wenzelm@28907
|
83 |
|
wenzelm@28907
|
84 |
|
wenzelm@28907
|
85 |
Shared pull/push access
|
wenzelm@29481
|
86 |
-----------------------
|
wenzelm@28907
|
87 |
|
wenzelm@28907
|
88 |
The entry point http://isabelle.in.tum.de/repos/isabelle is world
|
wenzelm@28907
|
89 |
readable, both via plain web browsing and the hg client as described
|
wenzelm@40849
|
90 |
above. Anybody can produce a clone, change it locally, and then use
|
wenzelm@40849
|
91 |
regular mechanisms of Mercurial to report changes upstream, say via
|
wenzelm@40849
|
92 |
mail to someone with write access to that file space. It is also
|
wenzelm@40849
|
93 |
quite easy to publish changed clones again on the web, using the
|
wenzelm@40849
|
94 |
ad-hoc command "hg serve -v", or the hgweb.cgi or hgwebdir.cgi scripts
|
wenzelm@40849
|
95 |
that are included in the Mercurial distribution, and send a "pull
|
wenzelm@40849
|
96 |
request" to someone else. There are also public hosting services for
|
wenzelm@40849
|
97 |
Mercurial repositories.
|
wenzelm@28907
|
98 |
|
wenzelm@28913
|
99 |
The downstream/upstream mode of operation is quite common in the
|
wenzelm@28907
|
100 |
distributed version control community, and works well for occasional
|
wenzelm@28907
|
101 |
changes produced by anybody out there. Of course, upstream
|
wenzelm@28907
|
102 |
maintainers need to review and moderate changes being proposed, before
|
wenzelm@40849
|
103 |
pushing anything onto the official Isabelle repository at TUM. Direct
|
wenzelm@40849
|
104 |
pushes are also reviewed routinely in a post-hoc fashion; everybody
|
wenzelm@40849
|
105 |
hooked on the main repository is called to keep an eye on incoming
|
wenzelm@40849
|
106 |
changes. In any case, changesets need to be understandable, at the
|
wenzelm@40849
|
107 |
time of writing and many years later.
|
wenzelm@28907
|
108 |
|
wenzelm@40849
|
109 |
Push access to the Isabelle repository requires an account at TUM,
|
wenzelm@40849
|
110 |
with properly configured ssh to the local machines (e.g. macbroy20,
|
wenzelm@40849
|
111 |
atbroy100). You also need to be a member of the "isabelle" Unix
|
wenzelm@40849
|
112 |
group.
|
wenzelm@28907
|
113 |
|
wenzelm@28913
|
114 |
Sharing a locally modified clone then works as follows, using your
|
wenzelm@28913
|
115 |
user name instead of "wenzelm":
|
wenzelm@28907
|
116 |
|
wenzelm@28913
|
117 |
hg out ssh://wenzelm@atbroy100//home/isabelle-repository/repos/isabelle
|
wenzelm@28907
|
118 |
|
wenzelm@28913
|
119 |
In fact, the "out" or "outgoing" command performs only a dry run: it
|
wenzelm@28913
|
120 |
displays the changesets that would get published. An actual "push",
|
wenzelm@28913
|
121 |
with a lasting effect on the Isabelle repository, works like this:
|
wenzelm@28907
|
122 |
|
wenzelm@28913
|
123 |
hg push ssh://wenzelm@atbroy100//home/isabelle-repository/repos/isabelle
|
wenzelm@28907
|
124 |
|
wenzelm@28913
|
125 |
|
wenzelm@40849
|
126 |
Default paths for push and pull can be configured in
|
wenzelm@40849
|
127 |
isabelle/.hg/hgrc, for example:
|
wenzelm@28907
|
128 |
|
wenzelm@28907
|
129 |
[paths]
|
wenzelm@28907
|
130 |
default = ssh://wenzelm@atbroy100//home/isabelle-repository/repos/isabelle
|
wenzelm@28907
|
131 |
|
wenzelm@28913
|
132 |
Now "hg pull" or "hg push" will use that shared file space, unless a
|
wenzelm@28913
|
133 |
different URL is specified explicitly.
|
wenzelm@28913
|
134 |
|
wenzelm@28913
|
135 |
When cloning a repository, the default path is set to the initial
|
wenzelm@28913
|
136 |
source URL. So we could have cloned via that ssh URL in the first
|
wenzelm@28913
|
137 |
place, to get exactly to the same point:
|
wenzelm@28913
|
138 |
|
wenzelm@28913
|
139 |
hg clone ssh://wenzelm@atbroy100//home/isabelle-repository/repos/isabelle
|
wenzelm@28907
|
140 |
|
wenzelm@28907
|
141 |
|
wenzelm@40849
|
142 |
Simple merges
|
wenzelm@40849
|
143 |
-------------
|
wenzelm@30182
|
144 |
|
wenzelm@30182
|
145 |
The main idea of Mercurial is to let individual users produce
|
wenzelm@30182
|
146 |
independent branches of development first, but merge with others
|
wenzelm@30182
|
147 |
frequently. The basic hg merge operation is more general than
|
wenzelm@30182
|
148 |
required for the mode of operation with a shared pull/push area. The
|
wenzelm@40849
|
149 |
"fetch" extension accommodates this case nicely, automating trivial
|
wenzelm@30182
|
150 |
merges and requiring manual intervention for actual conflicts only.
|
wenzelm@30182
|
151 |
|
wenzelm@40849
|
152 |
The fetch extension can be configured via $HOME/.hgrc like this:
|
wenzelm@30182
|
153 |
|
wenzelm@30182
|
154 |
[extensions]
|
wenzelm@30182
|
155 |
hgext.fetch =
|
wenzelm@30182
|
156 |
|
wenzelm@30182
|
157 |
[defaults]
|
wenzelm@30182
|
158 |
fetch = -m "merged"
|
wenzelm@30182
|
159 |
|
wenzelm@40849
|
160 |
To keep merges semantically trivial and prevent genuine merge
|
wenzelm@40849
|
161 |
conflicts or lost updates, it is essential to observe to following
|
wenzelm@40849
|
162 |
general discipline wrt. the public Isabelle push area:
|
wenzelm@40849
|
163 |
|
wenzelm@40849
|
164 |
* Before editing, pull or fetch the latest version.
|
wenzelm@40849
|
165 |
|
wenzelm@40849
|
166 |
* Accumulate private commits for a maximum of 1-3 days.
|
wenzelm@40849
|
167 |
|
wenzelm@40849
|
168 |
* Start publishing again by pull or fetch, which normally produces
|
wenzelm@40849
|
169 |
local merges.
|
wenzelm@40849
|
170 |
|
wenzelm@40849
|
171 |
* Test the merged result as usual and push back in real time.
|
wenzelm@40849
|
172 |
|
wenzelm@40849
|
173 |
Piling private changes and public merges longer than 0.5-2 hours is
|
wenzelm@40849
|
174 |
apt to produce some mess when pushing eventually!
|
wenzelm@30182
|
175 |
|
wenzelm@30182
|
176 |
|
wenzelm@28907
|
177 |
Content discipline
|
wenzelm@29481
|
178 |
------------------
|
wenzelm@28907
|
179 |
|
wenzelm@40849
|
180 |
The following principles should be kept in mind when producing
|
wenzelm@40849
|
181 |
changesets that are meant to be published at some point.
|
wenzelm@28907
|
182 |
|
wenzelm@40849
|
183 |
* The author of changes needs to be properly identified, using
|
wenzelm@40849
|
184 |
[ui]username configuration as described above.
|
wenzelm@28907
|
185 |
|
wenzelm@28907
|
186 |
While Mercurial also provides means for signed changesets, we want
|
wenzelm@28907
|
187 |
to keep things simple and trust that users specify their identity
|
wenzelm@40849
|
188 |
correctly (and uniquely).
|
wenzelm@28907
|
189 |
|
wenzelm@28907
|
190 |
* The history of sources is an integral part of the sources
|
wenzelm@28907
|
191 |
themselves. This means that private experiments and branches
|
wenzelm@40849
|
192 |
should not be published by accident. Named branches are not
|
wenzelm@40849
|
193 |
allowed on the public version. Note that old SVN-style branching
|
wenzelm@40849
|
194 |
is replaced by regular repository clones in Mercurial.
|
wenzelm@28907
|
195 |
|
wenzelm@40849
|
196 |
Exchanging local experiments with some other users can be done
|
wenzelm@40849
|
197 |
directly on peer-to-peer basis, without affecting the central
|
wenzelm@40849
|
198 |
pull/push area.
|
wenzelm@28907
|
199 |
|
wenzelm@28907
|
200 |
* Log messages are an integral part of the history of sources.
|
wenzelm@40849
|
201 |
Other people will have to inspect them routinely, to understand
|
wenzelm@40849
|
202 |
why things have been done in a certain way at some point.
|
wenzelm@28907
|
203 |
|
wenzelm@40849
|
204 |
Authors of log entries should be aware that published changes are
|
wenzelm@40849
|
205 |
actually read. The main point is not to announce novelties, but
|
wenzelm@40849
|
206 |
to describe faithfully what has been done, and provide some clues
|
wenzelm@40849
|
207 |
about the motivation behind it. The main recipient is someone who
|
wenzelm@40849
|
208 |
needs to understand the change in the distant future to isolate
|
wenzelm@40849
|
209 |
problems. Sometimes it is helpful to reference past changes via
|
wenzelm@40849
|
210 |
changeset ids in the log entry.
|
wenzelm@28907
|
211 |
|
wenzelm@40849
|
212 |
* The standard changelog entry format of the Isabelle repository
|
wenzelm@40849
|
213 |
admits several (vaguely related) items to be rolled into one
|
wenzelm@40849
|
214 |
changeset. Each item is then described on a separate line that
|
wenzelm@40849
|
215 |
may become longer as screen line and is terminated by punctuation.
|
wenzelm@40849
|
216 |
These lines are roughly ordered by importance.
|
wenzelm@40849
|
217 |
|
wenzelm@40849
|
218 |
This format conforms to established Isabelle tradition. In
|
wenzelm@40849
|
219 |
contrast, the default of Mercurial prefers a single headline
|
wenzelm@40849
|
220 |
followed by a long body text. The reason for that is a somewhat
|
wenzelm@40849
|
221 |
different development model of typical "distributed" projects,
|
wenzelm@40849
|
222 |
where external changes pass through a hierarchy of reviewers and
|
wenzelm@40849
|
223 |
maintainers, until they end up in some authoritative repository.
|
wenzelm@40849
|
224 |
Isabelle changesets can be more spontaneous, growing from the
|
wenzelm@40849
|
225 |
bottom-up.
|
wenzelm@40849
|
226 |
|
wenzelm@40849
|
227 |
The web style of http://isabelle.in.tum.de/repos/isabelle/
|
wenzelm@40849
|
228 |
accommodates the Isabelle changelog format. Note that multiple
|
wenzelm@40849
|
229 |
lines will sometimes display as a single paragraph in HTML, so
|
wenzelm@40849
|
230 |
some terminating punctuation is required. Do not squeeze multiple
|
wenzelm@40849
|
231 |
items on the same line in the original text!
|
wenzelm@28907
|
232 |
|
wenzelm@28907
|
233 |
|
wenzelm@32361
|
234 |
Building a repository version of Isabelle
|
wenzelm@32361
|
235 |
-----------------------------------------
|
wenzelm@28908
|
236 |
|
wenzelm@40849
|
237 |
Compared to a proper distribution or development snapshot, it is
|
wenzelm@40849
|
238 |
relatively hard to build from the raw repository version. Essential
|
wenzelm@40849
|
239 |
contributing components are missing and need to be reconstructed by
|
wenzelm@40849
|
240 |
running the Admin/build script by hand. Afterwards the main Isabelle
|
wenzelm@40849
|
241 |
system and logic images can be compiled via the toplevel ./build
|
wenzelm@40849
|
242 |
script. Note that the repository lacks some textual version
|
wenzelm@40849
|
243 |
identifiers in the sources and scripts; this implies some changed
|
wenzelm@40849
|
244 |
behavior when processing settings etc.
|
wenzelm@28908
|
245 |
|
wenzelm@40849
|
246 |
There is no guarantee that the NEWS file is up to date at an arbitrary
|
wenzelm@40849
|
247 |
point in history. |