README_REPOSITORY
author blanchet
Tue Dec 07 11:56:53 2010 +0100 (2010-12-07)
changeset 41052 3db267a01c1d
parent 40601 021278fdd0a8
child 47449 5e1482296b12
permissions -rw-r--r--
remove the "fin_fun" optimization in Nitpick -- it was always a hack and didn't help much
wenzelm@28907
     1
Important notes on Mercurial repository access for Isabelle
wenzelm@28907
     2
===========================================================
wenzelm@28907
     3
wenzelm@40601
     4
Introduction
wenzelm@40601
     5
------------
wenzelm@28907
     6
wenzelm@40601
     7
Mercurial http://www.selenic.com/mercurial belongs to the current
wenzelm@40601
     8
generation of source code management systems that follow the so-called
wenzelm@40601
     9
paradigm of "distributed version control".  This is a terrific name
wenzelm@40601
    10
for plain revision control without the legacy of CVS or SVN.  See also
wenzelm@40601
    11
http://hginit.com/ for an introduction to the main ideas.  The
wenzelm@40601
    12
Mercurial book http://hgbook.red-bean.com/ explains many more details.
wenzelm@40601
    13
wenzelm@40601
    14
Mercurial offers great flexibility in organizing the flow of changes,
wenzelm@40601
    15
both between individual developers and designated pull/push areas that
wenzelm@40601
    16
are shared with others.  This additional power demands some additional
wenzelm@40601
    17
responsibility to maintain a certain development process that fits to
wenzelm@40601
    18
a particular project.
wenzelm@28907
    19
wenzelm@40601
    20
Regular Mercurial operations are strictly monotonic, where changeset
wenzelm@40601
    21
transactions are only added, but never deleted.  There are special
wenzelm@40601
    22
tools to manipulate repositories via non-monotonic actions (such as
wenzelm@40601
    23
"rollback" or "strip"), but recovering from gross mistakes that have
wenzelm@40601
    24
escaped into the public can be hard and embarrassing.  It is much
wenzelm@40601
    25
easier to inspect and amend changesets routinely before pushing.
wenzelm@28907
    26
wenzelm@40601
    27
The effect of the critical "pull" / "push" operations can be tested in
wenzelm@40601
    28
a dry run via "incoming" / "outgoing".  The "fetch" extension includes
wenzelm@40601
    29
useful sanity checks beyond raw "pull" / "update" / "merge".  Most
wenzelm@40601
    30
other operations are local to the user's repository clone.  This gives
wenzelm@40601
    31
some freedom for experimentation without affecting anybody else.
wenzelm@40601
    32
wenzelm@40601
    33
Mercurial provides nice web presentation of incoming changes with a
wenzelm@40601
    34
digest of log entries; this also includes RSS/Atom news feeds.  There
wenzelm@40601
    35
are add-on browsers, notably hgtk that is part of the TortoiseHg
wenzelm@40601
    36
distribution and works for generic Python/GTk platforms.  The
wenzelm@40601
    37
alternative "view" utility helps to inspect the semantic content of
wenzelm@40601
    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@40601
    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@40601
    56
initial configuration requires at least an entry to identify yourself
wenzelm@40601
    57
as follows:
wenzelm@28907
    58
wenzelm@28907
    59
  [ui]
wenzelm@40601
    60
  username = XXX
wenzelm@28907
    61
wenzelm@40601
    62
Isabelle contributors are free to choose either a short "login name"
wenzelm@40601
    63
(for accounts at TU Munich) or a "full name" -- with or without mail
wenzelm@40601
    64
address.  It is important to stick to this choice once and for all.
wenzelm@40601
    65
The machine default that Mercurial produces for unspecified
wenzelm@40601
    66
[ui]username is not appropriate.
wenzelm@28907
    67
wenzelm@40601
    68
Such configuration can be given in $HOME/.hgrc (for each home
wenzelm@40601
    69
directory on each machine) or in .hg/hgrc (for each repository clone).
wenzelm@28907
    70
wenzelm@28907
    71
wenzelm@40601
    72
Here are some further examples for hgrc.  This is how to provide
wenzelm@40601
    73
default options for common commands:
wenzelm@28907
    74
wenzelm@28907
    75
  [defaults]
wenzelm@28907
    76
  log = -l 10
wenzelm@28907
    77
wenzelm@40601
    78
This is how to configure some extension, which is called "graphlog"
wenzelm@40601
    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@40601
    90
above.  Anybody can produce a clone, change it locally, and then use
wenzelm@40601
    91
regular mechanisms of Mercurial to report changes upstream, say via
wenzelm@40601
    92
mail to someone with write access to that file space.  It is also
wenzelm@40601
    93
quite easy to publish changed clones again on the web, using the
wenzelm@40601
    94
ad-hoc command "hg serve -v", or the hgweb.cgi or hgwebdir.cgi scripts
wenzelm@40601
    95
that are included in the Mercurial distribution, and send a "pull
wenzelm@40601
    96
request" to someone else.  There are also public hosting services for
wenzelm@40601
    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@40601
   103
pushing anything onto the official Isabelle repository at TUM.  Direct
wenzelm@40601
   104
pushes are also reviewed routinely in a post-hoc fashion; everybody
wenzelm@40601
   105
hooked on the main repository is called to keep an eye on incoming
wenzelm@40601
   106
changes.  In any case, changesets need to be understandable, at the
wenzelm@40601
   107
time of writing and many years later.
wenzelm@28907
   108
wenzelm@40601
   109
Push access to the Isabelle repository requires an account at TUM,
wenzelm@40601
   110
with properly configured ssh to the local machines (e.g. macbroy20,
wenzelm@40601
   111
atbroy100).  You also need to be a member of the "isabelle" Unix
wenzelm@40601
   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@28913
   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@28913
   124
wenzelm@28907
   125
wenzelm@40601
   126
Default paths for push and pull can be configured in
wenzelm@40601
   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@40601
   142
Simple merges
wenzelm@40601
   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@40601
   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@40601
   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@40601
   160
To keep merges semantically trivial and prevent genuine merge
wenzelm@40601
   161
conflicts or lost updates, it is essential to observe to following
wenzelm@40601
   162
general discipline wrt. the public Isabelle push area:
wenzelm@40601
   163
wenzelm@40601
   164
  * Before editing, pull or fetch the latest version.
wenzelm@40601
   165
wenzelm@40601
   166
  * Accumulate private commits for a maximum of 1-3 days.
wenzelm@40601
   167
wenzelm@40601
   168
  * Start publishing again by pull or fetch, which normally produces
wenzelm@40601
   169
    local merges.
wenzelm@40601
   170
wenzelm@40601
   171
  * Test the merged result as usual and push back in real time.
wenzelm@40601
   172
wenzelm@40601
   173
Piling private changes and public merges longer than 0.5-2 hours is
wenzelm@40601
   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@40601
   180
The following principles should be kept in mind when producing
wenzelm@40601
   181
changesets that are meant to be published at some point.
wenzelm@28907
   182
wenzelm@40601
   183
  * The author of changes needs to be properly identified, using
wenzelm@40601
   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@40601
   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@40601
   192
    should not be published by accident.  Named branches are not
wenzelm@40601
   193
    allowed on the public version.  Note that old SVN-style branching
wenzelm@40601
   194
    is replaced by regular repository clones in Mercurial.
wenzelm@28907
   195
wenzelm@40601
   196
    Exchanging local experiments with some other users can be done
wenzelm@40601
   197
    directly on peer-to-peer basis, without affecting the central
wenzelm@40601
   198
    pull/push area.
wenzelm@28907
   199
wenzelm@28907
   200
  * Log messages are an integral part of the history of sources.
wenzelm@40601
   201
    Other people will have to inspect them routinely, to understand
wenzelm@40601
   202
    why things have been done in a certain way at some point.
wenzelm@40601
   203
wenzelm@40601
   204
    Authors of log entries should be aware that published changes are
wenzelm@40601
   205
    actually read.  The main point is not to announce novelties, but
wenzelm@40601
   206
    to describe faithfully what has been done, and provide some clues
wenzelm@40601
   207
    about the motivation behind it.  The main recipient is someone who
wenzelm@40601
   208
    needs to understand the change in the distant future to isolate
wenzelm@40601
   209
    problems.  Sometimes it is helpful to reference past changes via
wenzelm@40601
   210
    changeset ids in the log entry.
wenzelm@28907
   211
wenzelm@40601
   212
  * The standard changelog entry format of the Isabelle repository
wenzelm@40601
   213
    admits several (vaguely related) items to be rolled into one
wenzelm@40601
   214
    changeset.  Each item is then described on a separate line that
wenzelm@40601
   215
    may become longer as screen line and is terminated by punctuation.
wenzelm@40601
   216
    These lines are roughly ordered by importance.
wenzelm@28907
   217
wenzelm@40601
   218
    This format conforms to established Isabelle tradition.  In
wenzelm@40601
   219
    contrast, the default of Mercurial prefers a single headline
wenzelm@40601
   220
    followed by a long body text.  The reason for that is a somewhat
wenzelm@40601
   221
    different development model of typical "distributed" projects,
wenzelm@40601
   222
    where external changes pass through a hierarchy of reviewers and
wenzelm@40601
   223
    maintainers, until they end up in some authoritative repository.
wenzelm@40601
   224
    Isabelle changesets can be more spontaneous, growing from the
wenzelm@40601
   225
    bottom-up.
wenzelm@40601
   226
wenzelm@40601
   227
    The web style of http://isabelle.in.tum.de/repos/isabelle/
wenzelm@40601
   228
    accommodates the Isabelle changelog format.  Note that multiple
wenzelm@40601
   229
    lines will sometimes display as a single paragraph in HTML, so
wenzelm@40601
   230
    some terminating punctuation is required.  Do not squeeze multiple
wenzelm@40601
   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@40601
   237
Compared to a proper distribution or development snapshot, it is
wenzelm@40601
   238
relatively hard to build from the raw repository version.  Essential
wenzelm@40601
   239
contributing components are missing and need to be reconstructed by
wenzelm@40601
   240
running the Admin/build script by hand.  Afterwards the main Isabelle
wenzelm@40601
   241
system and logic images can be compiled via the toplevel ./build
wenzelm@40601
   242
script.  Note that the repository lacks some textual version
wenzelm@40601
   243
identifiers in the sources and scripts; this implies some changed
wenzelm@40601
   244
behavior when processing settings etc.
wenzelm@28908
   245
wenzelm@40601
   246
There is no guarantee that the NEWS file is up to date at an arbitrary
wenzelm@40601
   247
point in history.