Mercurial > hg > mercurial-crew-with-dirclash

comparison doc/FAQ.txt @ 455:8d43dfdfb514

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
More FAQ updates -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 More FAQ updates manifest hash: 98447c3da5aefcc6c4071d03d8014944cf4cbb79 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCu3TCywK+sNU5EO8RArRjAJ0ZtMHztUL1cQw7FC0C3uJ0YIfKjwCfWfSe JndrQxPs1QeCPK/RbfYiKjE= =aMHP -----END PGP SIGNATURE-----
author mpm@selenic.com
date Thu, 23 Jun 2005 18:49:38 -0800
parents df83b2c306ac
children d6ac88a738c4
comparison
equal deleted inserted replaced
454:58d57594b802 455:8d43dfdfb514
120 effectively the sum of all the contents of the repository for that 120 effectively the sum of all the contents of the repository for that
121 change, it is impossible in Mercurial to simultaneously commit and add 121 change, it is impossible in Mercurial to simultaneously commit and add
122 a tag. Thus tagging a revision must be done as a second step. 122 a tag. Thus tagging a revision must be done as a second step.
123 123
124 124
125 .Q. What if I want to just keep local tags?
126
127 You can add a section called "[tags]" to your .hg/hgrc which contains
128 a list of tag = changeset ID pairs. Unlike traditional tags, these are
129 only visible in the local repository, but otherwise act just like
130 normal tags.
131
132
125 .Q. How do tags work with multiple heads? 133 .Q. How do tags work with multiple heads?
126 134
127 The tags that are in effect at any given time are the tags specified 135 The tags that are in effect at any given time are the tags specified
128 in each head, with heads closer to the tip taking precedence. 136 in each head, with heads closer to the tip taking precedence. Local
137 tags override all other tags.
129 138
130 139
131 .Q. What are some best practices for distributed development with Mercurial? 140 .Q. What are some best practices for distributed development with Mercurial?
132 141
133 First, merge often! This makes merging easier for everyone and you 142 First, merge often! This makes merging easier for everyone and you
185 194
186 Mercurial is primarily developed for UNIX systems, so some UNIXisms 195 Mercurial is primarily developed for UNIX systems, so some UNIXisms
187 may be present in ports. 196 may be present in ports.
188 197
189 198
190 .Q. How does signing work? 199 .Q. How does Mercurial store its data?
191 200
192 Take a look at the hgeditor script for an example. The basic idea 201 The fundamental storage type in Mercurial is a "revlog". A revlog is
193 is to sign the manifest ID inside that changelog entry. The manifest 202 the set of all revisions of a named object. Each revision is either
194 ID is a recursive hash of all of the files in the system and their 203 stored compressed in its entirety or as a compressed binary delta
195 complete history, and thus signing the manifest hash signs the entire 204 against the previous version. The decision of when to store a full
196 project to that point. 205 version is made based on how much data would be needed to reconstruct
197 206 the file. This lets us ensure that we never need to read huge amounts
198 More precisely: each file hash is an SHA1 hash of the contents of that 207 of data to reconstruct a object, regardless of how many revisions of it
199 file and the hashes of its parent revisions. The manifest contains a 208 we store.
200 list of each file in the project along with its current file hash. 209
201 This manifest is hashed similarly to the file hashes, incorporating 210 In fact, we should always be able to do it with a single read,
202 the hashes of the parent revisions. 211 provided we know when and where to read. This is where the index comes
212 in. Each revlog has an index containing a special hash (nodeid) of the
213 text, hashes for its parents, and where and how much of the revlog
214 data we need to read to reconstruct it. Thus, with one read of the
215 index and one read of the data, we can reconstruct any version in time
216 proportional to the object size.
217
218 Similarly, revlogs and their indices are append-only. This means that
219 adding a new version is also O(1) seeks.
220
221 Revlogs are used to represent all revisions of files, manifests, and
222 changesets. Compression for typical objects with lots of revisions can
223 range from 100 to 1 for things like project makefiles to over 2000 to
224 1 for objects like the manifest.
225
226
227 .Q. How are manifests and changesets stored?
228
229 A manifest is simply a list of all files in a given revision of a
230 project along with the nodeids of the corresponding file revisions. So
231 grabbing a given version of the project means simply looking up its
232 manifest and reconstruction all the file revisions pointed to by it.
233
234 A changeset is a list of all files changed in a check-in along with a
235 change description and some metadata like user and date. It also
236 contains a nodeid to the relevent revision of the manifest.
237
238
239 .Q. How do Mercurial hashes get calculated?
240
241 Mercurial hashes both the contents of an object and the hash of its
242 parents to create an identifier that uniquely identifies an object's
243 contents and history. This greatly simplifies merging of histories
244 because it avoid graph cycles that can occur when a object is reverted
245 to an earlier state.
246
247 All file revisions have an associated hash value. These are listed in
248 the manifest of a given project revision, and the manifest hash is
249 listed in the changeset. The changeset hash is again a hash of the
250 changeset contents and its parents, so it uniquely identifies the
251 entire history of the project to that point.
252
253
254 .Q. What checks are there on repository integrity?
255
256 Every time a revlog object is retrieved, it is checked against its
257 hash for integrity. It is also incidentally doublechecked by the
258 Adler32 checksum used by the underlying zlib compression.
259
260 Running 'hg verify' decompresses and reconstitutes each revision of
261 each object in the repository and cross-checks all of the index
262 metadata with those contents.
263
264 But this alone is not enough to ensure that someone hasn't tampered
265 with a repository. For that, you need cryptographic signing.
266
267
268 .Q. How does signing work with Mercurial?
269
270 Take a look at the hgeditor script for an example. The basic idea is
271 to use GPG to sign the manifest ID inside that changelog entry. The
272 manifest ID is a recursive hash of all of the files in the system and
273 their complete history, and thus signing the manifest hash signs the
274 entire project contents.
203 275
204 276
205 .Q. What about hash collisions? What about weaknesses in SHA1? 277 .Q. What about hash collisions? What about weaknesses in SHA1?
206 278
207 The SHA1 hashes are large enough that the odds of accidental hash collision 279 The SHA1 hashes are large enough that the odds of accidental hash collision
211 becomes a realistic concern. 283 becomes a realistic concern.
212 284
213 Collisions with the "short hashes" are not a concern as they're always 285 Collisions with the "short hashes" are not a concern as they're always
214 checked for ambiguity and are still long enough that they're not 286 checked for ambiguity and are still long enough that they're not
215 likely to happen for reasonably-sized projects (< 1M changes). 287 likely to happen for reasonably-sized projects (< 1M changes).
288
289
290